Datadog cost optimization: controlling hosts, ingestion, and custom metrics

Quick answer

Datadog cost is driven by several independent meters: infrastructure hosts (per host per month), log ingestion and retention (per GB and per million events indexed), custom metrics (billed per unique metric time series, which explode with high-cardinality tags), and per-product SKUs (APM, synthetics, RUM). The biggest surprises usually come from custom-metric cardinality and unindexed-versus-indexed log choices. Optimize by trimming high-cardinality tags, sampling and filtering logs before indexing, right-sizing host counts, and turning off products you do not use.

Datadog is powerful, and its bill reflects that: it meters many things independently, and several of them scale in ways that are easy to trigger by accident. Teams routinely find Datadog is one of their largest cloud-adjacent line items, sometimes rivaling the infrastructure it monitors. Controlling it means knowing which meter each dollar comes from.

What Datadog bills for

Meter	Billed by	Common surprise
Infrastructure	Per host per month	Counting short-lived and autoscaled hosts
Log management	Per GB ingested, per million events indexed	Indexing everything, not just what you query
Custom metrics	Per unique metric time series	High-cardinality tags multiplying series
APM, RUM, synthetics	Per host, session, or test	Products left on by default

The two meters that most often cause bill shock are custom metrics and logs. A single custom metric tagged with something high-cardinality (like user ID, request ID, or container ID) becomes thousands or millions of distinct time series, each billed. And log ingestion plus indexing can dwarf everything else if you index all logs rather than only the ones you actually search. These are the cost drivers hiding inside observability.

Tame custom-metric cardinality

Custom metrics are billed per unique combination of metric name and tag values, so cardinality is everything. Audit which metrics carry high-cardinality tags and drop the tags you do not aggregate on. Use metrics without limits and configure which tag dimensions are retained, so you keep the useful aggregations without paying for every unique series. Removing one runaway tag can cut a large slice of the custom-metrics bill instantly.

Control log ingestion and indexing

Datadog separates ingestion (getting logs in) from indexing (making them searchable), and indexing is where most log cost lives. Use ingestion pipelines to filter out noise before it counts, sample high-volume, low-value logs, and index only the logs you actually query, sending the rest to cheaper archive storage (rehydrate on demand). Set retention to match how far back you really search. This mirrors the tiering logic in object storage cost.

Right-size hosts and products

Infrastructure is billed per host, so autoscaling and short-lived containers can inflate the count; use the billing that accounts for high-water-mark versus average and understand how your host count is measured. Turn off products you are not actively using (APM, RUM, synthetics, and others each bill separately), and review the per-product SKUs regularly. Attribute Datadog cost to teams so owners see their observability spend, the same visibility discipline you apply to cloud cost. Reviewing the SaaS observability bill alongside your infrastructure bill, and pricing new monitoring before you enable it, keeps it proportional. See the resource catalog for how infrastructure is priced.

FAQ

Why is my Datadog bill so high?

Datadog meters many things independently, and several scale in ways easy to trigger by accident. The most common causes of bill shock are custom-metric cardinality (a high-cardinality tag like user or container ID multiplying into millions of billed time series) and log indexing (indexing all logs rather than only what you query). Host counts inflated by autoscaling and unused products left on also add up.

How are Datadog custom metrics billed?

Per unique metric time series, meaning each distinct combination of metric name and tag values counts. So cardinality drives the cost: tagging a metric with a high-cardinality dimension (user ID, request ID, container ID) turns one metric into thousands or millions of billed series. Trimming high-cardinality tags and retaining only the dimensions you aggregate on is the fastest way to cut custom-metric cost.

How do I reduce Datadog log costs?

Datadog separates ingestion from indexing, and indexing is where most log cost lives. Filter out noise in ingestion pipelines before it counts, sample high-volume low-value logs, and index only the logs you actually search, archiving the rest to cheaper storage and rehydrating on demand. Set retention to match how far back you realistically query rather than keeping everything indexed indefinitely.

What are the main Datadog cost drivers?

Infrastructure hosts (per host per month), log management (per GB ingested and per million events indexed), custom metrics (per unique time series, sensitive to tag cardinality), and per-product SKUs like APM, RUM, and synthetics that each bill separately. Custom-metric cardinality and log indexing usually cause the biggest surprises, while unused products left enabled quietly add to the total.

Does high-cardinality tagging increase Datadog cost?

Yes, dramatically. Because custom metrics are billed per unique metric-and-tag-value combination, adding a high-cardinality tag (one with many distinct values like user ID or container ID) multiplies a single metric into a huge number of billed time series. Removing one runaway high-cardinality tag can cut a large portion of the custom-metrics bill immediately, making cardinality control the top log-and-metric lever.

How does C3X relate to Datadog cost?

C3X prices the cloud infrastructure Datadog monitors from your Terraform before deploy, giving you the infrastructure-cost side at design time. While C3X does not bill Datadog itself, seeing infrastructure cost up front helps you apply the same cost discipline to observability: monitor what matters, attribute the spend, and avoid over-instrumenting resources whose cost you can already see.

What to do next

Bring the same cost discipline to your infrastructure that you apply to observability. C3X prices your resources before deploy. Start with the quickstart.