Infrastructure Monitoring

Infrastructure Monitoring is the product that visualizes the state of servers, containers, and cloud resources at the host level. The host map and process list let you grasp at a glance which box is struggling right now.

What it does

It collects measurements such as CPU, memory, and disk from monitored hosts and visualizes them at the granularity of lists, maps, and processes. It is the foundation on which Datadog monitoring is built.

When to use it

Use it to survey the whole environment on a single screen once the number of hosts has grown beyond what you can inspect one by one. It is also the starting point during an outage, when the first step is to isolate which host is involved.

An everyday analogy

It is like the monitors in a building's central control room that show all of the building's equipment. The temperature and power draw of each floor are lined up at a glance, and only the rooms with an anomaly change color to alert you.

What Infrastructure Monitoring Shows

Datadog Infrastructure Monitoring consists of four views: the Infrastructure List, which lists the monitored hosts; the Host Map, which tiles the whole environment onto one screen and shows state through color and shape (there is a container version of the map as well); the Containers View, which shows the containers in the environment in real time; and the Processes View, which descends to the individual processes running on a host (as of August 2026; source: Datadog Infrastructure documentation). Because the host map lets you switch grouping, filters, and the displayed metric, a view such as lined up by region and color-coded by CPU can be built in a few clicks. Once the host count passes a few dozen, a list can no longer keep up, so making the map the default entry point makes environment-wide anomalies easier to catch.

The Range of Metrics Collected by Default

From hosts where the Datadog Agent is installed, system metrics such as CPU, disk, IO, memory, network, NTP, and uptime are collected as core checks that are enabled by default (as of August 2026; source: Getting Started with the Agent). These fall within the per-host price, while custom metrics that send your application's own numbers are treated as a separate allotment (100 per host on Pro and 200 on Enterprise, pooled across the account). Keeping in mind the dividing line that basic OS values are included in host billing while your own numbers are counted against the allotment prevents misreading the bill later.

Collection Interval and Granularity

The official documentation states that the Agent can collect 75 to 100 system-level metrics every 15 to 20 seconds (as of August 2026; source: Getting Started with the Agent). Because the granularity is in seconds rather than minutes, a spike that lasted only a few dozen seconds remains as a waveform. Collected metrics are retained for 15 months on both Pro and Enterprise, which makes them usable not only for investigating recent outages but also for seasonal comparisons such as what things looked like at the same time last year (retention on the free plan is 1 day). Granularity and retention are unglamorous differences among monitoring products, but this is what determines whether the data for that exact moment still exists during a root-cause investigation.

The Pros and Cons of Monitoring in Duplicate with CloudWatch

Instances on AWS send metrics to CloudWatch at 5-minute intervals by default, and enabling detailed monitoring makes it 1-minute intervals (as of August 2026; source: AWS EC2 documentation). To collect additional metrics, CloudWatch also directs you to install an agent. The Datadog Agent, on the other hand, runs at 15 to 20 second intervals as described above and collects OS-internal values including memory by default. If you use both to their full extent, the monitoring investment for the same host is doubled and alerts fire twice. The organizing axis is which one to make the primary surface for investigation and notification. If Datadog is the primary surface, a division of roles in which CloudWatch is narrowed to the minimum alarms needed for AWS services' automatic recovery (such as the trigger conditions for autoscaling) trims the duplication. The opposite decision, narrowing which hosts to put on Datadog, is covered in the next section.

Handling Containers and Kubernetes

Containers can be monitored in real time in the Containers View, and for billing purposes, containers beyond the allotment included in the host price (5 containers per host on Pro, 10 on Enterprise) are added at 1 dollar per container-month (as of August 2026; annual contract; US region) (source: Datadog pricing page). The official billing documentation also includes Kubernetes nodes in the definition of a host. In other words, in a Kubernetes cluster the baseline is node count equals host count, and on top of that, if containers packed densely onto a single node exceed the allotment, additional charges arise. A design that tiles many small pods densely is efficient for infrastructure, but monitoring cost is sensitive to the container count; factor this tug-of-war into your estimate.

The Decision Axis for How Many Hosts Before Moving to Datadog

The free plan is limited to 5 hosts and 1 day of metric retention, and the paid Pro plan is 15 dollars per host per month (as of August 2026; annual contract; US region).

Infrastructure Monitoring plan comparison (as of August 2026; US region; USD)
PlanMonthly PriceMain Conditions
Free0Up to 5 hosts; 1 day of metric retention
Pro15 dollars per host (annual)Container allotment 5 / custom metric allotment 100 (per host)
Enterprise23 dollars per host (annual)Container allotment 10 / custom metric allotment 200 (per host)
Source: Datadog pricing page

The usable decision axis is less the host count itself than the frequency of cross-host investigation. As long as one person is watching a handful of servers and outage investigations are contained within a single host, the cloud provider's standard monitoring will often suffice. Once investigations that span hosts (isolating which layer is the cause) start happening several times a month, you are at the stage of weighing 15 dollars per host against the labor cost of investigation. If you proceed not all at once but by onboarding the core production systems first and widening from there, you can re-measure the cost-effectiveness along the way.

The First Step Starts with the Host Map

Before building out dashboards right after adoption, we recommend first opening the host map and surveying the whole environment. Looking at it while switching the grouping axis (environment, role, region, and so on) gives you a concrete feel for the granularity at which monitoring screens should be divided. That granularity carries over directly into the design of the dashboards you build later and how you set up alerts. Conversely, if you skip this and mass-produce individual graphs, you tend to end up with screens that are merely arranged rather than screens for looking at. Since Infrastructure Monitoring is also the foundation for monitors and alerts, the natural route after grasping the shape of the environment on the map is to move on to building notifications for the hosts that matter most.

Things to watch out for

  • This article is based on the official documentation and official pricing page as of August 2026. The prices in this article are examples at the time they were checked and do not reflect any price revisions made after writing.
  • In Kubernetes, nodes are counted as hosts. Estimate the base price first by node count, not by the number of pods or containers.
  • Cloud VMs monitored through integrations are also included among billable hosts (see the Datadog Agent guide for details).
ShareXB!