Datadog Pricing Calculator: Which Numbers Does It Miss?

Somebody opens a Datadog pricing calculator, types in a host count and a daily log volume, and gets a monthly figure. The figure goes in the budget. Four months later the invoice is a different number and nobody can say which line moved.

The calculator is not lying. It is doing multiplication, correctly, on quantities you handed it. The trouble is that the biggest lines on a Datadog bill are not quantities anyone can look up, and one of them depends on which version of the contract you were sold.

Our position: use a calculator for the order of magnitude and then stop using it. The numbers that actually track the invoice already exist inside Datadog, they cost nothing, and they come with a published margin of error.

What does a Datadog pricing calculator actually compute?

A rate card times quantities you supply, at list, for one month. A reasonable sanity check, and not an answer to the question people put to it, which is what the bill will be next March.

The gap is measurement. Datadog's pricing definitions page gives a different basis for each product, and they are not the same shape of number. Containers are charged "based on the fractional hours of monitored containers". Ingested logs are "the total number of gigabytes submitted to the Datadog Logs service". Indexed logs are "per million log events submitted for indexing at the rate designated for the retention policy you selected".

Totals, monthly averages, fractional hours and a trimmed peak, collected by a form that asks for all of them as though they were one kind of thing. We built the pre-signature version of this estimate out of EC2 and CloudWatch in the post on estimating a Datadog bill before you sign. This one is about the error bars on it.

Which custom metrics contract are you on?

Ask this before anything else. The same instrumentation produces two very different billable quantities depending on which contract you hold, and both models are in force right now.

The older one counts cardinality. The custom metrics billing page defines the unit: "A custom metric is uniquely identified by a combination of a metric name and tag values (including the host tag)." Billing takes "the total of all distinct custom metrics (also known as timeseries) for each hour in a given month" and divides by the hours in the month. A distribution emits five custom metrics per unique tag combination before anybody asks it for anything, and percentile aggregations double that. Ten billable metrics per tag combination, from one line of code. That is the mechanism behind the histogram that ate a whole allowance in the post on cutting an existing Datadog bill.

The newer one counts names. Datadog's page on Metric Name Pricing makes a name billable once it carries more than 100 indexed points in a month, with 10 million indexed points included per name, and it is explicit that the two live side by side: "If your contract uses Timeseries (cardinality) pricing, your metrics experience is unchanged."

So a fleet that looks ruinous under cardinality can be cheap under names, and a team emitting a handful of enormous metrics is the reverse. Get the answer from the order form, not the sales call.

Why can you not just enter a host count?

Because the host line is not a count. It is a peak with the top sliced off. The pricing page bills "the maximum count (high-water mark) of the lower 99% of those hourly readings, excluding the top 1%", and Database Monitoring is metered the same way on unique database hosts.

Over a 730-hour month that throws away roughly seven hourly readings and bills the highest one left standing. So neither number a person reaches for is right: the average is dragged down by nights and weekends, and the peak is exactly what gets discarded. One sustained busy afternoon a week sets your bill; a ten-minute scale-out does not. For a payments platform that means settlement day sets the host line and the mean never comes near it. The arithmetic of which hour wins is in the Grafana comparison, where the billing unit is the entire argument.

What is the trial number telling you?

More than a calculator, and still not a bill. The Plan and Usage page marks trial products with an indicator and shows "the estimated cost if no trial were active", while billable usage excludes "organization and product trial usage". Read the warning on the same page twice: "Allow up to 72 hours for this section to update." The usage metering API agrees that usage data "is delayed by up to 72 hours from when it was incurred". On Thursday the console can tell you about Monday.

Which meters beat the calculator?

The estimated usage metrics, which are free, and which hardly any account we inherit has ever graphed. The reference page lists one per product: datadog.estimated_usage.hosts, datadog.estimated_usage.containers, datadog.estimated_usage.logs.ingested_bytes and datadog.estimated_usage.logs.ingested_events, datadog.estimated_usage.apm.indexed_spans, and for a metric-name contract datadog.estimated_usage.billable.metrics and datadog.estimated_usage.billable.points.

These are near real-time rather than three days behind, which is what makes them worth alerting on. They also arrive with an error bar Datadog publishes itself: "There is a 10-20% difference between estimated usage and billable usage on average. Due to the nature of the estimations, the margin of error is larger for small usage." Carry that range into the conversation with finance. A single number invites an argument about whether it was wrong; a number with a vendor-published fifteen percent either side does not.

One trap in the query itself. The docs tell you to "use sum as the space aggregator (sum by) when querying estimated usage metrics", because many of them arrive split by tag or by child organisation. Graph one with avg and the dashboard reads a fraction of your real usage and looks reassuring. We did exactly that on a multi-org account and believed it for a week.

Can you tell whose usage it is?

Up to a point, and the point is three. Usage Attribution "summarizes usage at the end of each month and visualizes usage over time broken out by tags", generates month-to-date and hourly CSV files, and works on up to three tag keys. The first report takes 24 hours to turn up.

Three keys goes faster than it sounds. Pick team, environment and service and the budget is spent, and the keys only describe telemetry from the day they were applied. Whether to carry that split in accounts instead of tags is the argument in the post on who owns which number, and which figure belongs in the board pack is in the FinOps post.

The harder limit is what cannot be attributed at any price. Attribution "does not support product usage that cannot be tagged during instrumentation. For example, Incident Management Users, Parallel Testing Slots, and Audit Trail." Seats and slots sit outside the mechanism, so the chargeback will not reconcile to the invoice. Somebody has to own that remainder on purpose rather than find it in March.

What does a regulated account add to the estimate?

A retention decision the calculator prices as a rate and your auditor reads as a control. Indexed logs are billed "at the rate designated for the retention policy you selected", so 15 days and 180 days are two prices for the same events, and CERT-In's directions of 28 April 2022 ask for a rolling 180 days of logs maintained within Indian jurisdiction.

Pricing 180 days of everything at index rates is how a sensible estimate becomes an indefensible invoice. Index the fortnight on-call actually searches, and keep the regulator's 180 days in S3 in ap-south-1 where it is priced like storage. Which Datadog site the data lands in is a separate question.

What can you run on Monday?

Two jobs, about an hour between them.

Pull the billable summary for the last complete month and set it beside whatever the calculator said. The call needs the usage_read permission and a month parameter in ISO-8601 to month precision:

DD_API_HOST=api.ap1.datadoghq.com   # or api.datadoghq.com, api.datadoghq.eu

curl -sG "https://${DD_API_HOST}/api/v1/usage/billable-summary" \
  --data-urlencode "month=2026-09" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}"

Then build one dashboard from the estimated usage metrics, with sum as the aggregator, and put a monitor on the two lines that run away overnight: datadog.estimated_usage.logs.ingested_events and whichever custom metrics meter your contract uses. Set the threshold at your committed quantity divided by the hours in the month, not at a round number somebody liked the look of.

If the invoice and the calculator disagree by much more than a fifth, that is not estimation error. Something is being counted that nobody planned to count, and the attribution CSV is where you find it.

When is the calculator's number good enough?

When the decision it feeds is coarse, and when there is no account to measure. Three engineers, twenty hosts, no Kubernetes, under ten gigabytes of logs a day: a calculator gets close enough to say whether a procurement process is worth starting, and fifteen percent either way only matters once fifteen percent of the bill is somebody's salary. You also cannot meter a platform you have not built yet. Take the figure, add a fifth, and treat the first three invoices as the real estimate.

The short version

• Get your custom metrics model from the order form: cardinality or metric names. The same instrumentation gives wildly different answers under the two.
• Stop entering host counts. Work out the trimmed peak from the hours that are actually busy, which for most Indian fintechs means settlement day.
• Graph the estimated usage metrics with sum, alert on ingested log events and your metrics meter, and quote Datadog's own 10 to 20 percent as the error bar on the forecast.
• Reconcile against billable-summary monthly, and expect the data to be up to 72 hours behind.
• Index the fortnight your engineers search. Put the 180 days in S3 in ap-south-1.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.