Last reviewed: 19 July 2026. Review by: 19 October 2026. Prices are Datadog's published US annual-commitment list rates unless stated; contracts and included allotments vary.
Datadog bills can grow faster than host count because several dimensions are metered independently rather than through one per-host fee. Host charges are only the base. Under cardinality-based custom metric pricing, unique metric-and-tag combinations are counted. Logs and spans have separate ingestion and indexing dimensions, and retention changes the indexed rate. One high-cardinality tag can therefore change the bill without adding a host.
This is less about a hidden pricing trick than a mismatch between the dimension a team forecasts and the dimensions its telemetry creates. Host count may be predictable. Tag combinations, index membership, event count and retention often are not. The worked examples below use Datadog's published counting rules and rates to show the shape of the bill. They are illustrations, not estimates for a particular deployment.
What are you actually paying for?
A Datadog estate can be metered across dimensions that accumulate independently. These are selected public list rates:
| Dimension | Billing unit | Annual-commitment list rate |
|---|---|---|
| Infrastructure Pro | per host, per month | $15 |
| Infrastructure Enterprise | per host, per month | $23 |
| Container Monitoring | per container, per month | $1 |
| Custom Metrics, indexed | per 100, per month | $5 |
| Ingested Custom Metrics | per 100, per month | $0.10 |
| APM | per APM host, per month | $31 |
| APM ingestion | per ingested GB | $0.10 |
| APM indexed spans, 15-day retention | per 1 million | $1.70 |
| Logs ingestion | per ingested GB | $0.10 |
| Logs indexed events, 15-day retention | per 1 million | $1.70 |
| Database Monitoring | per database host, per month | $70 |
| Continuous Profiler | per profiled host, per month | $19 |
The rows below the host charges are not metered by host count. They follow the shape and destination of the telemetry. Datadog also sells bundles, standalone configurations and negotiated agreements, so adding public SKU prices does not necessarily reproduce an actual invoice. Existing customers should use their billing agreement and allotments, not the list rate, for a final model.
What counts as a custom metric?
Under Datadog's cardinality-based model, a custom metric is a unique combination of a metric name and its tag values, including the host tag. Billing uses the monthly average of distinct custom metrics submitted each hour. Submission frequency and query frequency do not determine that count. The number of distinct series does.
One metric name is therefore not one billable metric. A request-latency metric tagged by service, endpoint and status can create as many series as there are real combinations of those values.
Adding a tag does not always increase the count. Datadog's documentation gives an important qualification: a tag that is functionally derived from an already more-granular tag may add no new combinations. A tag that introduces genuinely independent values can multiply them.
Worked example: one tag changes the arithmetic
Assume a 200-host estate on Infrastructure Pro. Base infrastructure cost is 200 hosts at $15, or $3,000 per month. The plan includes 100 indexed custom metrics per host, pooled across the estate, giving an illustrative allotment of 20,000.
Now suppose a team records request latency as a DISTRIBUTION metric tagged by service, endpoint and status. If 3,000 combinations occur in production, the default distribution aggregations produce five custom metrics per combination. Enabling p50, p75, p90, p95 and p99 adds five more, bringing the total to ten per combination.
- 3,000 combinations x 10 = 30,000 custom metrics
- 30,000 less the 20,000 allotment = 10,000 above the allotment
- 10,000 / 100 x $5 = $500 per month at the public list overage rate
Then suppose someone adds pod_name, and each existing combination occurs across five pods:
- 15,000 combinations x 10 = 150,000 custom metrics
- 150,000 less 20,000 = 130,000 above the allotment
- 130,000 / 100 x $5 = $6,500 per month at the public list overage rate
In this simplified example, the host count stays fixed while the combined infrastructure and indexed custom metric figure moves from $3,500 to $9,500. The precise invoice would depend on hourly averages, actual combinations, the contract and controls such as Metrics without Limits. The mechanism is the point: a new independent tag value can multiply series count.
Metrics without Limits can separate ingested custom metric volume from the tags retained for indexing. That can materially reduce indexed cardinality, but excluded tags are no longer available for querying on that configured metric. It is a deliberate observability trade-off, not a free preservation of every query path.
Which metric types multiply?
Metric type can affect the number of indexed custom metrics:
- COUNT, RATE and GAUGE: one custom metric per unique tag combination.
- HISTOGRAM: five per combination with the default Agent-side aggregations.
- DISTRIBUTION: five per combination for default server-side aggregations, or ten when five percentile aggregations are enabled.
Both histogram aggregations and distribution percentiles are configurable. Datadog also offers Metric Name pricing, a different contract model based on metric names and datapoint volume rather than cardinality. The two models should not be mixed in one estimate. Confirm which one governs the account before modelling a change.
Why are logs and spans measured twice?
Logs and spans expose separate ingestion and indexing dimensions. Ingestion follows data volume in gigabytes. Indexing follows event or span count and retention. Included allotments can offset some usage, but the two dimensions still respond differently to workload changes.
Take 1 TB of logs in a month. At an average event size of 2 KB, that is approximately 500 million events. Using the public list rates, ingestion is 1,000 GB x $0.10, or $100. If all 500 million events are indexed for 15 days, indexing is 500 x $1.70, or $850.
The ratio changes with event size. The same 1 TB made up of 500-byte events contains approximately 2 billion events. At the same 15-day list rate, indexing is $3,400 while ingestion remains $100. The volume did not change, but event count did.
APM follows a similar structure: an APM host charge, ingested spans measured in gigabytes and indexed spans measured per million at a retention tier. Datadog documents a default 150 GB ingested-span allotment per APM host and a default 1 million indexed-span allotment per APM host, subject to the account's plan and contract. Unused allotment does not carry forward.
The practical conclusion is that volume control and indexing policy are separate cost controls. A reduction in bytes does not always produce a proportional reduction in indexed events, and vice versa.
How much does retention change the indexed rate?
The public rate rises with retention for the same indexed events:
| Retention | Per 1 million indexed log events | Per 1 million indexed spans |
|---|---|---|
| 3-day | $1.06 | not listed |
| 7-day | $1.27 | $1.27 |
| 15-day | $1.70 | $1.70 |
| 30-day | $2.50 | $2.50 |
Moving a log index from 3-day to 30-day retention changes the indexed-event rate by about 2.36 times. On 500 million indexed events, the illustrative list-rate difference is $530 versus $1,250 per month.
Flex Logs provides a different storage and retrieval model, listed at $0.05 per million events stored per month. That storage rate is not directly comparable with standard indexed-event pricing because product capabilities, query behaviour and related charges differ. Treat it as a separate workload option and model the complete cost and operational requirements before changing routing.
How does host metering interact with autoscaling?
Datadog documents two host billing plans. Under the high watermark plan, hosts are metered hourly and billing uses the maximum of the lower 99 per cent of hourly measurements, excluding the top 1 per cent. Under the hybrid monthly/hourly plan, the customer commits to a monthly minimum and pays an hourly rate above it.
The 1 per cent exclusion only removes a small number of readings. A 730-hour month contains about 7.3 hours in the excluded top 1 per cent. A fleet that doubles for two hours every night spends about 60 hours at the higher level, so most of those readings remain inside the billed 99 per cent. Elastic estates should compare both plans against actual hourly history rather than annualised average host count.
How do containers change the arithmetic?
Container Monitoring is another dimension. Infrastructure Pro includes five containers per host and Enterprise includes ten by default. The allowance is pooled across the estate, and Datadog meters containers in five-minute increments. Agent containers and Kubernetes pause containers are excluded.
This means node consolidation changes both host cost and container allowance. Consider 500 containers on Infrastructure Pro at public annual rates:
- 50 hosts, 10 containers per host: allowance 250; billable containers 250 at $1; hosts $750; total $1,000.
- 25 hosts, 20 containers per host: allowance 125; billable containers 375 at $1; hosts $375; total $750.
Consolidation still wins in this example, but halving the host count does not halve the combined figure. Part of the host saving returns as container overage. The right model includes both dimensions.
A container in a pod stuck in CrashLoopBackoff can also count when it runs for more than ten seconds in a metering interval. A failed deployment left active can therefore continue contributing to usage.
Why does the month-two bill jump?
Host counts are known when an initial estimate is prepared. Custom metric cardinality, indexed span volume and log event count become visible only after real traffic and production instrumentation are flowing. The dimensions that are hardest to forecast are often the ones that do not follow host count.
That timing creates a recognisable pattern: the initial estimate reflects infrastructure; later invoices reveal telemetry shape. A pre-production cost model should therefore include expected tag cardinality, event-size distribution, indexing rules and retention, then be checked against usage data as soon as production traffic appears.
When is Datadog worth the cost?
Datadog can be good value when the organisation actively uses its breadth across infrastructure, APM, RUM, synthetics and security, and the alternative would be several systems with separate operating costs. A managed platform can also be economically sensible for a small, stable estate or a team without spare platform engineering capacity.
The model deserves closer examination when high-cardinality custom instrumentation is central to operations, log volumes are large but much of the data is rarely queried, or the marginal vendor spend is large enough to fund the engineering required for another architecture.
The comparison must use actual contracted rates and realistic engineering costs. Public list pricing alone cannot determine whether staying or migrating is cheaper.
What reduces the bill without a migration?
In rough order of leverage:
- Use Metrics without Limits deliberately. Keep only the tags needed for queries and monitors in the indexed definition, understanding that excluded tags are no longer queryable for that configured metric.
- Audit metric types and aggregations. Disabling percentiles that are not queried can halve a distribution's series multiplier from ten to five.
- Remove tags that add no useful independent granularity. Start with identifiers such as pod, customer and request IDs, but assess operational need before dropping them.
- Set retention by index. Route high-volume, short-lived operational data differently from data with a genuine long-term investigation requirement.
- Use trace ingestion controls and retention filters. Align indexed spans with the traces engineers actually investigate.
- Match the host plan to workload shape. Model high watermark and hybrid billing against hourly measurements.
- Model containers and hosts together. Include the allowance lost when nodes are consolidated and remove monitoring from containers that do not need it.
- Ask whether Metric Name pricing fits. It is a separate, contract-dependent model and may suit workloads whose cardinality profile is difficult to control.
Frequently asked questions
Why does a Datadog bill grow faster than host count?
Host licences are only one dimension. Custom metric cardinality, ingestion, indexed events and spans, retention, containers and other products can grow independently of the number of hosts.
What causes custom metric costs to increase?
Under cardinality-based pricing, each unique combination of metric name and tag values counts as a custom metric. A tag that adds independent values, such as a pod name, can multiply the number of series.
How can teams reduce Datadog costs without migrating?
Start with indexed cardinality, metric aggregations, log indexes and retention, trace retention filters, and host-plan fit. These controls address the dimensions that create many surprises while preserving the option to migrate later.
When is Datadog worth the cost?
It can be good value when its integrated breadth is actively used, the estate is small or stable, platform engineering capacity is scarce, or negotiated rates make the total cost competitive. Compare actual contracts and operating costs, not list prices alone.
Related reading
References
All sources checked 19 July 2026. Prices change frequently.