Why your Datadog bill grows faster than your product
Most Datadog products are priced per unit of usage. Hosts grow roughly with traffic. Custom metrics, indexed logs and indexed spans grow with something else: how many services you run, how many tags each metric carries and how much each service logs. Engineers decide those things one pull request at a time, and nobody sees the price of a tag when they add it.
That is how a bill can double in a year in which traffic grew by a third. In this article I go through the four meters that make up most Datadog bills, run a worked example at list prices, and list what I change first when I want the number to come down.
All prices below are Datadog list prices in US dollars from the Datadog pricing page and the custom metrics billing docs. Prices checked on 24 October 2026. They are the same prices my observability cost calculator uses. Negotiated contracts often differ, so treat the figures as a model of how the bill behaves, not as a quote.
The four meters
| Meter | Unit | List price | What makes it grow |
|---|---|---|---|
| Infrastructure (Pro) | Host per month | $15 billed annually, $18 on demand | Nodes, including autoscaling peaks |
| Custom metrics | Per 100 over the allotment | Not published; set in your contract | Tag combinations |
| Logs | GB ingested, plus million events indexed | $0.10 per GB; $1.70 per million (annual) or $2.55 (on demand) at 15-day retention | Log lines, share indexed, retention |
| APM | APM host per month | $31 annual, $36 on demand (with Infrastructure) | Hosts running traced services, spans over the allotment |
Hosts: you pay for nearly the busiest hour
Datadog meters hosts every hour and bills the high-water mark of the lower 99% of those hours, so the top 1% is excluded (billing docs). In a 730-hour month, that 1% is about seven hours. If your autoscaler holds extra nodes for a day of peak traffic each month, that peak sets the host count for the whole month.
Containers have their own meter. The pricing page FAQ says each host license covers 5 containers on Pro (10 on Enterprise) and that additional containers are billed at $0.002 per container per hour. A container that runs all month is 730 hours, or $1.46. A Kubernetes node running 30 containers with only 5 included pays about $36 a month for the other 25, more than its $15 host fee. My calculator leaves this line out, so if your nodes are dense, add it yourself.
Custom metrics: the meter engineers set without noticing
The billing docs define a custom metric as “a combination of a metric name and tag values (including the host tag)”. Three rules from those docs drive most of the cost:
- Every distinct combination counts. A metric with a
hosttag on 40 hosts is 40 custom metrics before any other tag is added. - Usage is counted every hour and averaged over the month, so short-lived tag values still cost something in the hours they exist.
- Histograms count as 5 custom metrics per combination. Distributions count as 5, and 10 once you enable percentiles.
The Pro plan includes 100 custom metrics per host, pooled across the account. Above that, the docs say you pay “an amount that is specified in your current contract” per 100. Datadog does not publish the rate. USD 5 per 100 is a figure often cited, and I use USD 1 as an assumed negotiated rate for the low end. Log-based metrics also count against the custom metrics allotment, according to the pricing page FAQ.
Here is how one metric gets expensive. Take a request-latency distribution with percentiles, tagged with endpoint (30 values) and status_class (4 values), on a service running 12 pods with a pod_name tag. That is 30 × 4 × 12 = 1,440 combinations, times 10, so 14,400 custom metrics from one metric name. Once the allotment is used up, it adds $144 to $720 a month. Now someone adds a customer tag with 50 values to see per-customer latency. The same metric becomes 720,000 custom metrics: $7,200 to $36,000 a month at the same rates. Nothing about traffic changed.
Pod names make it worse. Every rollout replaces them, so during a deploy the old and the new pod names both exist, and the hourly count for every pod-tagged metric goes up. Teams that deploy many times a day pay for that in the monthly average.
Logs: you pay to send them, then again to search them
Ingestion costs $0.10 per GB of uncompressed data, for everything you send. Indexing, which is what makes logs searchable and usable in monitors, costs $1.70 per million events billed annually ($2.55 on demand) at 15-day retention. If an average log event is about 1 KB, which is the assumption my calculator makes, a GB holds about a million events, so indexing a GB costs 17 to 25 times more than ingesting it.
Exclusion filters stop logs from being indexed. The index docs say excluded logs still flow through Live Tail, log-based metrics and archives, which means they are still ingested and still billed at the ingestion rate. A filter saves the indexing part only.
Retention is a price multiplier. Standard Indexing lists 3, 7, 15 and 30-day options, but the page only prints the 15-day price. For indexed spans, where it prints all three, 7 days is $1.27, 15 days $1.70 and 30 days $2.50 per million, billed annually. For long retention Datadog sells Flex Logs, from $0.05 per million events stored per month plus compute that is priced on request.
APM: per host, plus spans
APM costs $31 per host per month billed annually ($36 on demand) when attached to Infrastructure. The pricing FAQ says the number of containers on a host does not change the APM price. Each APM host includes 150 GB of ingested spans and 1 million indexed spans per month (15-day retention), pooled across APM hosts. Beyond that, ingested spans cost $0.10 per GB and indexed spans $1.70 per million at 15 days.
The usual way this grows is quiet. Tracing gets enabled in a shared base image or Helm chart, the traced services spread to every node, and every node becomes an APM host.
A worked example at list prices
These inputs are illustrative. They are not a client’s numbers. I picked growth rates that show the mechanism; plug your own into the calculator.
- Month 1: 40 hosts, 50,000 custom metrics, 30 GB of logs a day, all indexed at 15-day retention, 15 APM hosts.
- Month 13: traffic grew and the cluster grew with it to 52 hosts (+30%). Two new services shipped and one latency metric gained a tag, so custom metrics reached 120,000. Logs doubled to 60 GB a day. APM hosts went to 20.
- Assumptions: annual-billing prices, custom metric overage at $5 per 100, about 1 KB per log event, 30.4 days in a month, no containers over the allotment, no span overage.
| Line | Month 1 | Month 13 |
|---|---|---|
| Infrastructure Pro | 40 × $15 = $600 | 52 × $15 = $780 |
| Custom metrics over the allotment | (50,000 − 4,000) ÷ 100 × $5 = $2,300 | (120,000 − 5,200) ÷ 100 × $5 = $5,740 |
| Log ingestion | 912 GB × $0.10 = $91 | 1,824 GB × $0.10 = $182 |
| Log indexing, 15 days | 912 million events × $1.70 = $1,550 | 1,824 million events × $1.70 = $3,101 |
| APM | 15 × $31 = $465 | 20 × $31 = $620 |
| Total per month | $5,007 | $10,423 |
| In euros (ECB rate of 23 October 2026, 1 EUR = 1.1193 USD) | €4,473 | €9,312 |
Hosts grew by 30%. The bill grew by 108%. The host line, the one that tracks traffic, went from 12% of the bill to 7.5%. Custom metrics went from 46% to 55%, and logs stayed around a third.
At the assumed negotiated rate of $1 per 100 custom metrics, the totals are $3,167 and $5,831 a month: still 84% growth on 30% more hosts. The overage rate changes the size of the bill. The shape stays the same.
The calculator works with ranges instead of single values (between half and all logs indexed, $1 to $5 per 100 custom metrics, annual to on-demand prices) and puts a self-hosted estimate next to it, including the engineering time to run it.
What drives the growth
Tags with many values. pod_name, container_id, host, customer or tenant IDs, user IDs and raw URL paths each multiply the series count of every metric they are attached to. The agent adds Kubernetes tags on its own: most are low-cardinality, like namespace and deployment, but pod_name comes in at orchestrator cardinality and container_id only at high (Kubernetes tag docs).
Log volume nobody reads. Debug logging left on after an incident, health-check and access logs, retry loops that log every attempt, and stack traces split into many events. If the default index takes everything, each of these lines is paid for twice.
Retention set once and never revisited. Index retention that matched a compliance question years ago, or 30-day span retention for services nobody traces back that far.
Hosts that are not production. Staging, preview and load-test clusters running the full agent with APM, billed at the same rate as production.
What I change first
I work from the usage breakdown in the Datadog account, not from the invoice: usage per product, and for custom metrics, usage per metric name. Then, roughly in this order:
- Remove tags nobody queries. The cheapest fix is at the source: stop sending
pod_name,container_idand ID-style tags on metrics where nobody groups by them, and check the agent’s tag cardinality setting. If you cannot change the code quickly, Metrics without Limits lets you choose which tags stay indexed. It is not free: the docs bill ingested custom metrics of configured metrics at $0.10 per 100 over the account allotment. - Keep percentiles where someone reads them. They double a distribution’s count.
- Drop logs before they are sent. Filter debug and health-check lines in the agent or collector, because an exclusion filter still pays ingestion. Turn high-volume access logs into metrics, shorten index retention to what incidents actually need, and archive the rest to your own object storage.
- Trace on purpose. Enable APM on the services where people use traces, and sample the rest.
- Look at non-production. Decide which environments need full monitoring, and check what your autoscaler’s monthly peak does to the host count.
These steps usually come before any migration, because they are cheap and reversible. The structural option comes after: move the largest usage line, often custom metrics, to a Prometheus-compatible stack you run yourself. On the RESTIA platform, which I designed and run, 13 months of about 68,000 active series are sized at about 22 GB (projected from a measured 0.26 bytes per sample), and the metrics database runs within 2 GiB of RAM and 1 CPU. At the list prices above, the same metrics would cost an estimated €670 to €3,100 a month in Datadog (68,000 series billed as custom metrics on 5 to 9 billed hosts, metrics only, computed with the calculator’s prices). Running it yourself has costs too: machines and engineering time. The calculator counts both.
If you go that way, the cardinality and retention checklist for Prometheus-compatible stacks covers the same discipline on the other side: the series count still decides the cost, it just shows up as RAM and disk instead of an invoice line.
Get your own numbers
Start with the observability cost calculator. It takes hosts, custom series, log volume, retention and APM hosts, and shows a range for your vendor and for a self-hosted stack with every price and assumption listed. If you want someone to go through your actual usage, the Observability Cost Review does it in five working days, and this article explains what I check.
Sources
Checked on 24 October 2026:
- Datadog, Pricing: host, log, APM, span and container prices, and the FAQ on log-based metrics and containers.
- Datadog, Custom metrics billing: counting rules, allotment and overage.
- Datadog, Billing: hourly host metering and the 99th percentile rule.
- Datadog, Log indexes: exclusion filters.
- Datadog, Kubernetes tag extraction: tag cardinality levels.
- European Central Bank, euro reference rates: 1 EUR = 1.1193 USD on 23 October 2026.