Datadog Custom Metrics Pricing & Bill Optimization (2026)

Datadog is known among engineering teams for two things: its observability products, and the complex bill that comes with them. Plenty of people struggle just to understand how Datadog bills them in the first place, which is why we broke down the full Datadog pricing model in a separate blog. But custom metrics pricing is confusing enough to deserve its own dedicated post, so we've covered it in detail here.

This blog walks through how Datadog actually bills custom metrics, what counts as one, how cardinality drives the total, what each plan includes, and how Datadog features such as, Metrics without Limits and Metric Name pricing change the math. Every figure here comes from Datadog's official billing documentation as of July 2026. By the end, you'll be able to decode your Datadog custom metrics pricing and know exactly what you're paying for.

What Counts as a Datadog Custom Metric?

Datadog considers a metric "custom" if it isn't emitted by one of its 1,000+ built-in integrations. That includes anything you send yourself through DogStatsD  or a custom Agent check, the extra metrics that some standard integrations emit beyond their defaults, and application-defined OTel metrics or unmapped receiver metrics. The important part is how they're counted: a custom metric is uniquely identified by the combination of a metric name and its tag values, including the host tag. So a single metric name can expand into many billable custom metrics, depending on how you tag it.

For example, say you emit a metric called request.latency tagged with region (values: us, eu) and status (values: 200, 400). The number of custom metrics is the product of the distinct values across your tags, so 2 regions × 2 statuses = 4 unique combinations. Each combination counts as its own custom metric:

# Four Custom Metrics
request.latency{region:us, status:200}
request.latency{region:us, status:400}
request.latency{region:eu, status:200}
request.latency{region:eu, status:400}

That's one metric name, but four custom metrics on your bill. This is why cardinality matters so much. The count multiplies with every tag you add. Introduce a high-cardinality tag like user_id with 1,250 active users, and that same metric jumps to 2 × 2 × 1,250 = 5,000 custom metrics.

Every Datadog plan comes with a base allotment of custom metrics, pooled across your entire infrastructure rather than locked to individual hosts. Anything beyond that allotment is billed as overage:

Coming back to example, let's put a price on it. On the Pro plan, a single host includes 100 indexed custom metrics, so 5,000 on that host leaves 4,900 over your allotment. At $5 per 100 indexed custom metrics, that's (4,900 ÷ 100) × $5 = $245 per month, or roughly $2,940 a year, from a single over-tagged metric.

How the Monthly Custom Metrics Bill Is Calculated

Datadog doesn't bill you for the peak number of custom metrics you hit during the month, it bills you on an average. It counts your distinct custom metrics (timeseries) for every hour, then divides the total by the number of hours in the month to get a monthly average. That average is what your bill is based on, not how often you send datapoints or how many queries you run against them.

This detail matters more than it looks. A metric that spikes to 50,000 timeseries for one hour and sits near zero the rest of the month barely moves your bill. A metric that steadily holds 5,000 timeseries all month is what costs you. So when you're hunting down a surprise charge, look for sustained cardinality, not brief spikes.

Metrics Without Limits

This is where the ingested vs. indexed split from earlier comes back. By default, every custom metric you send is both ingested (received by Datadog) and indexed (kept queryable), and you're billed on the indexed count. Metrics without Limits lets you keep sending everything while choosing which tags stay queryable, which shrinks your indexed volume and, with it, your bill. Take the request.latency example again. Say you drop the high-cardinality user_id tag from indexing but keep region and status. Your indexed count falls from 5,000 back down to 4 combinations, while all 5,000 are still ingested so the raw data isn't lost.

The trade-off is that, once a metric is configured with Metrics without Limits, you're billed for its ingested volume too ($0.10 per 100 ingested over your allotment), on top of the indexed charge.

Metric Name Pricing

Everything above describes Datadog's cardinality-based (Timeseries) model, which is what most accounts are on. Some contracts instead use a completely separate model called Metric Name pricing, and you're on one or the other, never both.

Under this model you get billed on the number of unique metric names you submit plus the volume of datapoints those names produce. Each billed metric name includes 10 million indexed datapoints, and anything beyond that pools into a singles monthly overage bucket priced across volume-based tiers.

The two models reward completely different habits, so it's worth confirming which one your contract uses before you start optimizing:

How to Reduce Your Datadog Custom Metrics Bill

Custom metrics are one of the biggest and quietest cost drivers in Datadog, often making up 50% or more of a bill once high-cardinality tags creep in. The good news is that most of the overage comes from a handful of metrics, so a focused cleanup usually recovers the bulk of it. Here's where to start, roughly in order of impact.

1. Eliminate high-cardinality tags

Each unique metric name + tag combination is its own billable timeseries, so one unbounded tag can turn a single metric into thousands. Never tag with user_id, UUIDs, request_id, session_id, or timestamps. Instead, replace them with low-cardinality groupings.

2. Consolidate redundant and duplicate metrics

Audit for duplicate metrics across teams, drop metrics already provided out of the box, and collapse per-service counters into a single metric where you don't need the breakdown.

3. Use Metrics without Limits to index only what you query

For metrics where you still want the raw data ingested but don't query every tag, configure Metrics without Limits to index only the tag combinations you actually filter or group by. Just remember the trade-off from earlier, configured metrics bill on both ingested and indexed volume, so use it where the indexed savings clearly outweigh the ingested cost.

4. Trim aggregations on Histogram and Distribution metrics

• A Histogram generates five custom metrics by default (avg, count, median, max, and the 95percentile). Control these with the histogram_aggregates and histogram_percentiles parameters in your Agent's datadog.yaml. Drop the aggregations and percentiles you don't query.

• A Distribution generates five by default (count, sum, min, max, avg), and enabling percentile aggregations (p50, p75, p90, p95, p99) doubles that to ten. Distribution percentiles are toggled per-metric in the Datadog UI (or via the API), not in the Agent config, so review them there.

5. Monitor usage and set alerts

Treat your custom metrics volume like any other monitored system. Use the Metrics Summary page to find your top metrics by cardinality, clean up ones not queried in 30+ days, and set cost monitors that fire when custom metrics grow more than a few percent week over week. Guardrails keep cardinality from quietly creeping back after a cleanup.

Still, these tactics are ultimately damage control. Once your team is trimming useful tags or managing a second billing configuration just to keep costs in check, the pricing model is fighting how you actually use metrics, which is why many teams start weighing Datadog alternatives.

SigNoz Cloud: Datadog Alternative Without the Custom Metrics Tax

Look back at your own custom metrics prices you are paying for a moment. How much of it is buying you real insight, and how much is just the cost of Datadog metering every unique tag combination as its own billable series? For most teams, the answer is uncomfortable, a few high-cardinality metrics quietly drive the bulk of the spend. That's the core issue with a Datadog's pricing model. It charges you for exactly what modern, high-cardinality applications naturally produce.

SigNoz on other hand takes a different approach, and here's how the two compare on the things that actually move a custom metrics bill:

Run your own calculation against above table. If your bill is dominated by custom metrics and high-cardinality tags, the gap isn't a rounding difference.

SigNoz is an all-in-one, OpenTelemetry-native observability platform that unifies metrics, traces, and logs in a single application. Because it's built around OpenTelemetry, sending metrics through OTel doesn't trigger a custom-metric surcharge, and there's no separate ingested-vs-indexed split to manage. You can emit high-cardinality metrics like per-user counters and pay only for the number of metric samples, $0.10 per million metric samples with every series included. The instrumentation belongs to you, not the vendor, so your telemetry stays portable if you ever switch.

Whether Datadog's model fits your architecture is a call only you can make, and it's best made with your own bill in front of you. If the pattern you keep seeing is cardinality-driven overages you didn't forecast, it's worth putting a predictable, volume-based model next to your next Datadog quote before you renew. For teams already on Datadog, the migration guide walks through moving dashboards and instrumentation instead of rebuilding them by hand.

Get started with SigNoz

The easiest way to get started with SigNoz is SigNoz cloud. We offer a 30-day free trial account with access to all features.

Those who have data privacy concerns and can't send their data outside their infrastructure can sign up for either enterprise self-hosted or BYOC offering.

Those who have the expertise to manage SigNoz themselves or just want to start with a free self-hosted option can use our community edition.

FAQs

Why is my Datadog bill higher than my data volume suggests?

Datadog's custom metrics are billed on cardinality, the number of unique metric-name and tag combinations, not on the size of the data you send. A low-volume metric with a few high-cardinality tags (like user_id or request_id) can generate thousands of billable timeseries, while a high-volume metric with a couple of simple tags stays cheap. If your bill feels disconnected from your actual data, tagging is almost always the reason.

Are OpenTelemetry metrics cheaper on Datadog?

No. Datadog bills metrics sent through OpenTelemetry at the same custom-metric rates as any other custom metric, with no discount for using an open standard. So moving to OTel doesn't lower your custom metrics cost on Datadog by itself, the same cardinality-based pricing still applies.

Does Metrics without Limits actually help?

It can. Metrics without Limits lets you keep ingesting high-cardinality data while indexing only the tags you actually query, which lowers the indexed count your bill is based on. The trade-off is added complexity. The configured metrics are billed on both ingested and indexed volume, so you're managing two meters instead of one. It's worth it for high-cardinality metrics you rarely query in full, but you have to set it deliberately.

What is the fastest way to cut my custom metrics bill?

Open the Metrics Summary page, sort by volume, and audit the tags on your most expensive metrics. In most accounts, a handful of metrics with runaway cardinality drive the majority of the overage, and removing or grouping those high-cardinality tags (for example, replacing user_id with user_tier) recovers most of the cost without any contract changes.