Datadog cost: what drives the bill and how to control it

Read the bill as separate meters

Datadog does not charge one price for "monitoring". Each product has its own unit. The pricing page lists them product by product.

So the first step is a table: product, billing unit, current usage, and who owns it. Datadog documents separate billing and usage permissions. Ask for Usage Read to inspect usage and Usage Attribution. Changing the attribution setup needs Usage Edit. Subscription and payment details need Billing Read. Ask an administrator for any other access you need.

What each meter counts

These are the units as the pricing page and the billing docs describe them. Check them against your own plan, because allotments differ by plan and by contract.

• Infrastructure hosts: billed per host, per month. A host is any physical or virtual OS instance you monitor. Hosts are metered hourly. Datadog drops the top 1 percent of hourly counts, so short spikes do not set the bill.
• Containers: the Pro plan includes 5 containers per host and the Enterprise plan includes 10 (pricing page). Containers above that are billed per container per hour.
• Custom metrics: a custom metric is one metric name plus one set of tag values, including the host tag. Datadog counts distinct custom metrics each hour and averages them over the month. How often you send data points does not change the count.
• Logs: two meters. Ingest is billed per GB ingested or scanned. Index is billed per million log events kept for search. Retention is chosen per index.
• APM: billed per APM host, per month. Ingested spans are billed in GB at the end of the month. Indexed spans are billed per million. Each APM host includes an amount of both (150 GB ingested and 1 million indexed per host, per the APM billing page).

Which meters grow with scale

This is how the billing works, not a ranking. Host and container counts follow your infrastructure. The other meters follow your data.

Custom metric counts depend on the distinct tag-value combinations actually sent. In Datadog's example, four observed combinations give four count or gauge metrics. The same four combinations give 20 histogram metrics with the default aggregations. A new tag raises the count only if it creates additional combinations.

Indexed logs grow with the number of log events you keep searchable. A new service that logs on every request adds to it. Datadog bills the events indexed during the month, and use above your commitment is billed as on-demand.

Ingested and indexed spans grow with request volume and with how many traces your sampling rules keep. Datadog bills indexed spans by the retention filters you set.

Controls Datadog offers

Work from the largest meter down. For each one, Datadog has a control in its own product.

• Metrics without Limits: Datadog says it decouples ingestion cost from indexing cost. You keep sending data and choose which tags stay queryable. In the docs example, keeping two tags cuts one metric from 4 indexed custom metrics to 3, while ingested stays at 4. Ingested volume is only counted for metrics you configured.
• Log exclusion filters: excluded logs are discarded from indexes. The docs say they still flow through Live Tail, and still feed log-based metrics and archives. Use them for high-volume, low-value logs. Confirm with Datadog how excluded logs count toward the ingest meter.
• Log daily quotas: a quota per index limits how many events get indexed per day. After the limit, logs are no longer indexed but still reach Live Tail and archives. Datadog suggests a monitor that fires at 80 percent of the quota.
• Trace ingestion controls: the Ingestion Control page shows each service and lets you set sampling rules. Sort by Downstream Bytes/s to find the largest sources. With OpenTelemetry, SDK sampling also affects APM trace metrics. To calculate metrics from all traffic, send all spans to the Collector's span_metrics connector. Do this before you apply sampling.
• Retention filters: these decide which spans are indexed, and so which spans are billed as indexed spans.
• Usage Attribution: breaks usage down by up to three tag keys, with CSV files and an API. Usage Read lets you view it. Changing the setup needs Usage Edit. Only usage that can be tagged when you instrument is included.

Watch usage before the invoice

Datadog publishes estimated usage metrics, for example datadog.estimated_usage.apm.ingested_bytes and datadog.estimated_usage.apm.indexed_spans. For logs, the default usage metrics track ingested logs, ingested bytes and indexed logs. Datadog notes that these are estimates and may differ from official billing numbers.

Put these on a dashboard and add a monitor per meter. Tag your services and teams first, so Usage Attribution can show who causes which part.

Keep the option to change tools

Datadog supports OpenTelemetry. If your applications emit OpenTelemetry data, the instrumentation is not tied to one vendor. The place you send it to can change.

Datadog's OpenTelemetry page lists these ways to send traces, metrics and logs: the Datadog Agent with the DDOT Collector, an OpenTelemetry Collector, the Datadog Agent as an OTLP receiver, and direct OTLP ingestion. Datadog recommends the Agent with the DDOT Collector. It describes direct ingestion as the option for cases where running a Collector or Agent is not possible.

With a Collector, the destination is a few lines of configuration. This sample is trimmed from the Datadog docs. The docs say to use their full configuration for production.

This forwarding example does not generate APM trace metrics. It does not add host or cloud metadata either. Use Datadog's full configuration for those features.

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
exporters:
  otlp_http:
    endpoint: https://otlp.${env:DD_SITE}
    headers:
      dd-api-key: ${env:DD_API_KEY}
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp_http]
    metrics:
      receivers: [otlp]
      exporters: [otlp_http]
    logs:
      receivers: [otlp]
      exporters: [otlp_http]

Order of work

A short order that fits most teams:

• Get Usage Read access and write down each meter with its current usage.
• Set tag keys for Usage Attribution (team, service, environment). This needs Usage Edit.
• Take the largest meter first and use its control: tags, exclusion filters, quotas or sampling.
• Add usage monitors, so a new log source or tag does not surprise you.
• Use OpenTelemetry for new services, and check in a test environment that your views still work.