The whole estate on one screen.
Counted once, and billed once.
Datadog Infrastructure Monitoring collects metrics from every host, container and cloud service you run. We implement it, filter out the hosts that should never have been billed, and run it every month so the invoice still matches the estate a year from now.
Quick facts
Related
- Container Monitoring, Kubernetes, ECS and Fargate counted correctly
- Network Monitoring, the traffic between the hosts
- APM, the request that ran on the host
Every box, including the ones nobody remembers building
A disk fills on a server that was meant to be decommissioned in 2025. Nothing is monitoring it, because nobody knew it was still there. Infrastructure Monitoring is the inventory that keeps itself up to date, with the metrics attached.
One Agent, everything on the box. CPU, memory, disk, network and the processes running, plus the integration checks for whatever the host is for: the database, the queue, the web server, the cache.
The cloud account fills in the rest. The AWS, Azure and Google Cloud integrations bring in the managed services the Agent cannot sit on, and the instances that have not got an Agent yet.
A host map you can filter. Tags from the Agent and tags from the cloud account meet in one place, so env, role, team and region slice the estate the way the org chart does.
Monitors that notice absence. A host that stops reporting is as important as a host that is on fire. No-data monitors, disk forecasts and per-role saturation alerts page the right people before the customer notices.
A cloud integration with no filter, a tag that means two things, and the host nobody told Datadog about
How it bills. Hosts are recorded every hour and billed on the high-water mark of the lower 99 per cent of those readings. A host is any machine running the Agent and any instance the cloud integrations discover, counted once when both apply. Each host carries an allotment of containers and of custom metrics, and usage above either allotment is metered on its own. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The configuration is.
The configuration traps. The cloud integration tile, left at its default, monitors every instance in every connected account. Build runners, bastion hosts, autoscaled test environments and the instance someone forgot to terminate all become hosts on the high-water mark. The Agent config ships with sensible defaults and no tags, so the host map works until two teams use env to mean different things. Integration checks enabled wholesale emit metrics nobody dashboards. None of this raises an alert. All of it reaches the invoice.
Field noteThe most common gap we see is the cloud integration filter. The AWS tile was connected during the trial with no tag filter, and every account added since has brought its instances with it. The host count on the invoice includes machines the platform team has never logged into.
Field noteTags are set in the Agent config by hand, once, during the rollout. The cloud integration brings a second set from the account. The two disagree on environment names, so hosts carry both, and every view grouped by env counts the same host twice.
Field noteNo-data monitors are the ones nobody builds. A host that stops reporting leaves the dashboards quietly, and the first sign that it has gone is the service it was running going with it.
Field noteAgent versions drift across the fleet. The oldest hosts run a version from before the features the newest dashboards assume, so the same disk looks healthy on one row and absent on the next.
Decide what counts as a host before Datadog decides for you
A new rollout starts with LaunchPad, which runs the implementation as a managed project with a named engineer and a written scope. If the Agent is already out there, a Datadog HealthScan comes first. It is read-only and fully automated, and it reports host counts, integration filters and tag consistency before we change anything. Either way, the sequence is the same.
- Inventory the estate and the accounts. Every cloud account, every region, every host that exists today, and who owns it. The list is compared with what Datadog can already see.
- Decide what counts as a host. Which roles get the Agent, which are covered by the integration alone, and which are filtered out by tag. The decision is written down with the reason.
- Set the tags in configuration management. env, role, team and region defined once, applied by the tooling that builds the host, never by hand on the box.
- Roll the Agent out by environment. Non-production first, with the integration checks each role needs and nothing else. Production follows once the host map looks right.
- Build the monitors and the dashboard pack. No-data per role, disk forecast, saturation per role, with thresholds taken from a fortnight of real data rather than a round number.
- Hand over, in writing. What was configured, which filters were set, what the host count was on the day we finished, and which allotments had headroom.
Access is admin on the Datadog organisation plus read access to the cloud accounts and the configuration management repository. We do not need production shell access to implement Infrastructure Monitoring, and we do not ask for it.
The estate changes every week. The filters were set once.
A new account is connected. An autoscaling group doubles for a launch and never comes back down. A team adopts a new tag convention without telling the other teams. Managed Observability is the monthly service that keeps Infrastructure Monitoring matching the estate it watches.
Every month, we reconcile the host count. The billed high-water mark against the inventory, the container and custom metric allotments against usage. Anything that moved gets a reason or a fix.
Coverage follows the estate. New accounts, new regions and new roles are found in the host map review and either filtered or instrumented before they are the host everyone is looking for.
Monitors earn their place. A monitor that has not fired for a real reason in a quarter is retired or rebuilt. Alert noise is a configuration problem, and configuration is what we run.
The incident is ours to take. Under Critical Support our engineers answer the page the host raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An implementation partner installs the Agent and hands over. A managed partner is still there when a new account is connected in March and the host count jumps. We are the second kind. The Agent config, the integration filters and the decisions behind them stay in your Datadog organisation and your configuration management, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Infrastructure Monitoring, answered plainly
How is Datadog Infrastructure Monitoring billed?
The main meter is hosts. Datadog records the host count every hour and bills on the high-water mark of the lower 99 per cent of those hours. The top one per cent of readings is discarded, so a sustained peak sets the bill. A host is any machine running the Agent and any instance the cloud integrations discover, counted once when both apply. Each host carries an allotment of containers and custom metrics, and usage above the allotment is metered separately. We do not publish prices. The meters are what we tune.
Do cloud integration hosts count towards the Datadog host bill?
Yes. An EC2 instance, Azure virtual machine or Compute Engine instance that the cloud integration picks up is a billable host whether or not the Agent is installed on it. An instance with both the integration and the Agent is counted once. The integration tiles accept tag filters, and those filters decide which instances are monitored and which are not. Setting them is the first thing we check.
Do we need the Datadog Agent on every host?
No. The cloud integration gives basic metrics for every instance it can see. The Agent gives process, disk, integration and container detail, and it is what most monitors are built on. The decision is per role: production hosts and anything with a database or queue on it get the Agent, short-lived build runners and bastion hosts usually do not. Writing that decision down is part of the implementation.
Does Datadog Infrastructure Monitoring cover containers and Kubernetes?
It does, through the same Agent. Each host carries a container allotment, and the Containers Explorer and Kubernetes views come with it. Container-heavy estates have their own configuration decisions, so we cover them on the Container Monitoring page. Serverless platforms such as Lambda and Cloud Run are billed on their own meters and have their own page too.
What does Critical Cloud do with Infrastructure Monitoring every month?
Managed Observability runs it. Every month we reconcile the billed host count against the estate inventory, check the cloud integration filters against the accounts and regions that exist now, review the container and custom metric allotments, retire monitors that no longer fire for a real reason, and report what changed. Under Critical Support our engineers also take the page when a host goes wrong, 24x7.
- Datadog products: every product, and how we implement and run each one
- Infrastructure Observability Accelerator: infrastructure, APM and logs operational in four weeks
- Datadog pricing and cost optimisation: the whole bill, not just hosts
A host count you recognise. An estate you can see.
Tell us how many hosts you think you have. We will tell you how many Datadog thinks you have, why the two differ, and what it takes to make them agree.