How to Decode Datadog's Pricing Structure - Billing Units by SKU and How to Prevent Billing Accidents

Why the price list is hard to read - stacked SKUs and three unit prices

What first confuses someone opening Datadog's price list for the first time is that there is no single answer to "how much is Datadog per month." Each product, such as Infrastructure Monitoring, APM, and Log Management, defines SKUs (billing items) with different billing units, and the actual bill is the sum of the SKUs for the products you used stacked together. On the official pricing page as of August 2026, more than 100 SKUs are defined per region (source: Datadog Pricing page). Furthermore, multiple unit prices are listed side by side for the same SKU: annual, month-to-month, and on-demand. The stock phrase in the pricing page footnotes is "Billed annually or $X on-demand," a structure in which the annual unit price and the on-demand unit price are always shown as a pair. If you estimate from a single number like "15 dollars per host" without knowing this structure, a gap from the actual bill is guaranteed. This article lays out the order in which to read this pricing structure so that you can predict the actual bill, based solely on official primary sources as of August 2026. Note that the prices in this article are examples at each point in time and do not reflect price revisions made after writing.

Stage 1 - confirm the billing unit for each SKU

The first stage of decoding, before the amounts, is confirming "what is counted to bill you" = the billing unit. In Datadog, what is counted changes by product even for the same monitored target. Per-host, per-GB, per-event, per-session, and per-test-run units are all mixed together, and getting these wrong throws an estimate off by an order of magnitude. The billing units and unit prices (US region, USD, monthly) for the major SKUs as of August 2026 are as follows.

What to take from this table is not the individual amounts but the "design of the units." Infrastructure Monitoring and APM scale with the number of hosts, logs and traces scale with flow volume, and Synthetics scales with the number of runs. In other words, even with the same configuration, if traffic grows only the flow-based SKUs grow, and if you raise test frequency only Synthetics grows: they grow independently. Figuring out in advance "which axis tends to grow" in your environment is the starting point for reading the price list.

Stage 2 - read down to the "counting" rules

The second stage is the "counting" rules behind the billing units. This is actually what influences the bill the most. The official billing documentation defines counting rules that do not appear in the price list (as of August 2026; source: Datadog Billing documentation). To name the main ones: first, the host count is finalized at month end as the maximum of hourly measured usage excluding the top 1% (the 99th percentile high-water mark). In other words, even if the host count jumps in a momentary spike, that top 1% is excluded from the bill. On the other hand, in environments where autoscaling kicks in routinely, the "commonly occurring maximum" becomes the billed host count as is, so estimating from the average host count will miss. Next, custom metrics are counted as the monthly average of the number of distinct series per hour, and submission frequency does not affect billing (source: Custom Metrics Billing documentation). Furthermore, the billing cycle begins on the 1st of every month (UTC) regardless of signup date. The practical lesson to draw from this is: before the multiplication of "unit price × host count," confirm "how that host count or that volume is counted." The same 100 hosts means something different for the bill when it is 100 around the clock versus 100 by day and 20 at night. It is also worth knowing that some SKUs have no unit price on the public price list. For example, the overage beyond the custom metrics allotment is defined only as "the unit price stated in your contracted plan per 100 in excess," with no public price. Knowing which items cannot be pinned down at the estimation stage makes clear what to confirm in contract negotiations.

The five typical types of billing accident

When a Datadog bill exceeds expectations, the cause can almost always be classified into the following five types.

Types 1 and 5 are especially dangerous. Custom metrics are counted as one per "combination of metric name and tag values (including host tags)" (as of August 2026; source: Custom Metrics Billing documentation). In other words, even if you think you added just one metric, attaching a tag with many distinct values such as a user ID creates as many billable series as there are values. The allotment (100 per host on Pro, pooled across the account) is easily exhausted in the face of this bloat. For Synthetics, the official page itself shows an example of the multiplication. Because a browser test is converted to one run per 25 steps, running a 60-step test (worth 3 runs) every 15 minutes across 5 locations × 2 devices comes to 120 runs per hour from that alone, and by simple arithmetic over 80,000 runs per month. The unit price of 12 dollars per 1,000 runs on an annual contract looks cheap, but after the multiplication it can reach the scale of 1,000 dollars per month.

Defensive settings - make it visible, then narrow

Preventing billing accidents starts with "making usage visible." Datadog provides a usage (Usage) page in the admin screens, and access to billing-related pages is limited to the administrator role or roles with billing read permission (as of August 2026; source: Datadog Billing documentation). There are two things to do on the first day of adoption. First, build usage checks into weekly operations. If you only notice when the invoice arrives, a month's worth of accident is already locked in. Since Monitors and Alerts already give you the monitoring machinery, including "Datadog's own usage" among your monitored targets is a sound way to use it. Second, design ingestion controls for the flow-based products before full-scale adoption. For logs, a two-stage arrangement of ingesting everything while narrowing the index is possible, and the design procedure is covered in the Log Management explanation. Traces likewise can have their flow adjusted through ingestion sampling controls and selection of what to retain (see the APM explanation). The decision axis to hold onto here is that "narrowing" can wait until things are visible. If you narrow aggressively right after adoption, you never obtain the measured value of how much telemetry your environment actually produces, and the accuracy of the estimate described in the next section does not improve.

Estimation procedure - grow from measurements of a minimal configuration

Given all of the above, it is rational to build an accurate estimate from measurements rather than desk calculations. The procedure can be organized into the following five stages.

The crux of this procedure is the fifth stage. Annual unit prices are 0 to just over 30% cheaper than on-demand. Host-based SKUs are roughly in the 10% range and flow-based ones like logs and RUM around 30% (for example, log 30-day indexing is 2.50 versus 3.75 dollars, making annual 33% cheaper, while some SKUs such as log ingestion have no difference), so the economic motive to commit can be confirmed on the price list. But committing without the backing of measurements exposes you to both risks: a commitment shortfall if you do not use it, and expensive settlement if you exceed it. Dividing it as "the floor you will certainly use on annual, the variable ceiling on-demand" is the way of reading that turns the three-tier structure of the pricing to your advantage. If you want to go as far as comparing configurations, choosing between Datadog and CloudWatch and the comparison with New Relic are the follow-on reading, and for the adoption decision itself, the adoption checklist. To repeat the caution one last time, all unit prices in this article are public values for the US region as of August 2026 and do not reflect price revisions made after writing. Before signing a contract, always confirm the values at that time on the official pricing page.