How to Think About Datadog APM Pricing - Three Host Price Tiers and Span Allotments

Conclusion - APM Has Three Price Tiers, and the Difference Is Bundled DSM and Profiler

The APM price list shows three tiers: APM / APM Pro / APM Enterprise. Every tier is billed as a monthly amount per APM host, and with each step up, Data Streams Monitoring (DSM = tracking of data pipelines) and Continuous Profiler (code-level CPU / memory analysis) are bundled in (source: Datadog Pricing / APM Billing). The unit prices on the price list are those for use together with Infrastructure Monitoring; the unit price for contracting APM alone does not appear on the public price list (source: Datadog Pricing). There are three contract forms - annual, monthly, and on-demand - and within the same tier the annual-contract unit price is the lowest, with monthly and on-demand set higher.

The pricing model as a whole is left to How to Decode the Pricing Structure; this article focuses on APM. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

Allotments Are Pooled Across All Hosts, Not Per Host

Since the two-story structure of billing was covered in the APM explanation, here we focus on the allotment pooling rule. The allotments of 150 GB of Ingested Spans and 1 million Indexed Spans (15-day retention) come with each APM host, but whether you have exceeded them is judged on the total across all hosts. In the official example, even if one of two hosts sends 250 GB and the other 50 GB, the 300 GB total fits within the 300 GB allotment for two hosts, with no additional charge (as of September 2026; source: the FAQ on Datadog Pricing). The number of hosts is measured hourly and billed at the 99th percentile at month end after discarding the top 1%, a design in which temporary increases in host count are unlikely to affect the bill. The billing documentation explicitly states that if you place an Agent per container, each container is counted as one host, and that on Kubernetes counting is per node, not per Pod (source: APM Billing).

Billing for Overages - Two Tracks: Ingested GB and Indexed Span Count

Overage beyond the allotments is billed separately, with ingestion (Ingested) per GB and indexing (Indexed) per million spans. The overage unit price for indexed spans is higher the longer the retention period (7 / 15 / 30 days), and the structure in which the unit price rises in the order annual, monthly, on-demand is the same as for host billing (source: Datadog Pricing). The official billing documentation includes a worked example of a month in which a handful of APM hosts send more spans than their allotment, and the bill is assembled by adding three lines: "host count × host unit price", "indexed spans over the allotment (in millions) × indexing unit price", and "ingested GB over the allotment × ingestion unit price".

In the official example, even though several times the allotment in spans is indexed and ingestion also exceeds the allotment, the total overage comes in below the host billing. The point at which overage charges become the main actor on the bill is decided by the ratio of the unit price per million indexed spans to the unit price for one host. Check that ratio on the official pricing page; as long as the number of million-span units over the allotment does not reach it, reviewing the host count has more effect on the bill than adjusting ingestion controls.

The More Small Hosts in the Configuration, the More Host Billing Bites

Even when sending the same volume of traces, the more hosts you have, the more the bill swells. Fix the monthly volume of Ingested Spans and Indexed Spans that the application as a whole sends, and vary only how many hosts it runs on.

Whether reducing the host count and falling short of the allotment pays off is decided by the size of the host billing you removed versus the overage billing you incurred. A simple way to judge it is to compare, using the figures on the official pricing page, the cost of buying back one host's worth of allotment (Ingested 150 GB + Indexed 1 million) entirely as overage against the unit price of one host. If the former is below the latter, reducing hosts and paying for the overage is cheaper. Particular care is needed with the rule that placing an Agent per container counts each container as one host; adopting the sidecar approach on Kubernetes increases APM hosts by the number of Pods. As covered in Container Monitoring, with a deployment of one Agent per node, billing stays at the node level. The decision to narrow which hosts have APM enabled is the single move with the largest effect on billing.

How Lambda and Fargate Are Counted

Since serverless has no unit called a host, the counting changes. The official billing page explains that in serverless no billable APM hosts arise; billing is based on the monthly total of Lambda invocations tied to APM ingested spans, with Indexed Spans beyond the bundled amount billed separately (as of September 2026; source: Serverless Billing).

Because Fargate's allotments are smaller than the host-based ones, in Fargate-centered configurations build the indexed span count estimate first. For Lambda, the invocations of functions that are instrumented and under monitoring become the billed quantity as is, so choosing which functions to instrument is the means of adjustment (source: Serverless Billing).

Are APM Pro / Enterprise Cheaper Than Adding the Standalone SKUs?

DSM and Continuous Profiler also have standalone SKUs, and both are billed as a monthly amount per host separately from APM (source: Datadog Pricing). Whether to step up the tier and bundle them on all hosts, or to put the standalone SKUs only on the hosts that need them, is decided by the share of hosts that use the feature. As long as the increase in the host unit price from stepping up one tier (the tier gap) is smaller than the standalone SKU's unit price, stepping up is cheaper if you use the feature on all hosts, and if only some hosts use it, "standalone SKU unit price × hosts that use it" comes in below "tier gap × all hosts". The break-even point is the share given by "tier gap ÷ standalone SKU unit price", and you can decide by whether the hosts that handle data pipelines such as Kafka exceed that share. Plug in the figures from the official pricing page for the unit prices. The official FAQ states that both can also be purchased standalone (as of September 2026; source: APM Billing).

Estimate in the Order "Host Count → Measured Ingested GB → Indexing Rate"

First, count the hosts. Multiplying the hosts you plan to enable APM on (nodes, in the case of Kubernetes) by the tier's unit price determines most of the monthly cost. Next, measure the ingestion volume. Looking at the usage metrics datadog.estimated_usage.apm.ingested_bytes and datadog.estimated_usage.apm.ingested_spans during a pilot rollout tells you whether you fit within the allotment of 150 GB × host count (as of September 2026; source: APM Billing). Checking on the usage screen is left to How to Check Your Costs. Finally, decide the indexing rate and retention days (the longer the retention, the higher the unit price for indexed spans). Since the portion of spans ingested through distributed tracing that gets indexed can be selected with retention filters, decide on a rate that fits within the allotment of 1 million × host count. The design thinking is left to the "Sampling design" section of the APM explanation. In the reverse order, you end up trimming only the small cost items without touching the host billing that makes up most of the bill.