How to Check Your Datadog Costs - The Usage Screen and Usage Attribution

Billing Is Not Something You Learn at Month End - Three Places to Check

What organizations that have Datadog billing accidents have in common is learning the amount for the first time from the invoice at month end. Billing is a monthly cycle starting on the 1st (UTC); hosts and custom metrics are measured hourly, and the billed amount is settled in aggregate at month end (as of September 2026, Source: Billing). In other words, even mid-month, "usage so far" accumulates every hour, and three windows for viewing it are provided. The first is the Plan & Usage usage screen that administrators open, where you check the cumulative total since the start of the month (Month-to-Date) by product. The second is Usage Attribution, a mechanism that divides the same usage by team or environment tags and turns it into "who used how much". The third is the usage metrics provided under the name datadog.estimated_usage.*, which you can put on monitors just like any other metric and be notified the moment they spike. These three have different roles. The screen is for "reading near-final figures monthly", attribution is for "handing them back to teams", and metrics are for "having machines watch daily changes"; any one alone is not enough. This article follows how to use them in this order and finally turns them into a weekly routine. How to read the pricing model itself is covered in How to Decode the Pricing Structure, so this article concentrates on "where to look to find out".

What the Plan & Usage Usage Screen Shows, and What It Does Not

The usage screen appears when an administrator (Administrator role) opens Plan & Usage from the account menu at the bottom left and proceeds to the Usage tab. There are tabs by product category, and the All tab lists the Month-to-Date usage for the current month of infrastructure hosts, containers, custom metrics, APM hosts, logs, and so on. The first thing to understand here is that the "counting method" for the figures differs by product. Infrastructure hosts and APM hosts are defined as the 99th percentile across all hours of the current month, custom metrics as the average across all hours, ingested logs as the total bytes, indexed logs and spans as the total event count, and Synthetics as the total number of test runs (as of September 2026, Source: Usage Details). Hosts being the 99th percentile reflects the billing rule of charging the maximum after excluding the top 1% of hours, a design under which a brief autoscaling spike in host count is unlikely to hit the bill (Source: Billing).

Also keep in mind what it does not show. First, this screen is stated to take up to 72 hours to update, so it is not the value "right at this moment". Second, the All view includes usage that is not billed, such as products in trial, and to see only the billed portion you need to switch to the Billable view (the Billable view is available on most accounts and breaks down into committed, allotment, and on-demand portions). Third, First-time usage notifications, which email you when a product outside your contract is used for the first time, and the display that highlights on-demand portions with a purple label are treated as beta as of September 2026 and require a request through your account representative (Source: Plan & Usage, Usage Details).

Usage Attribution Turns Usage into "Who Used How Much" by Tags

Even if you know the total usage, reduction does not progress unless you can hand it back to teams. Usage Attribution is one of the tabs in Plan & Usage, a feature that breaks usage down by up to 3 tag keys (such as team, env, and service) and generates monthly and hourly CSVs. It can be opened by administrators or users with the Usage Read permission; it takes 24 hours from configuring the tags until the first report appears, and it is updated daily thereafter. The monthly report is a Month-to-Date aggregation, can show both values and percentages in the table, and the CSV contains both usage and percentages, so it can be used directly as the source data for departmental allocation (chargeback) (as of September 2026, Source: Usage Attribution). There are three constraints to know as prerequisites. First, products that cannot be tagged at instrumentation time are out of scope, and the official documentation cites Incident Management user counts, CI Pipeline / Test user counts, parallel test slots, and Audit Trail as examples. Next, if you change tag keys mid-month, that month is split into partial reports by period. Finally, if the tag for the unit you want to allocate by is not attached to all resources in the first place, the report simply leaves a thick "untagged" row. Because Tag design directly determines allocation accuracy, the work of baking the team tag into Agent configuration and deployment templates comes first. For direct billing contracts, a cost allocation report for the previous month is also generated at month end and becomes available by the 19th of the following month. Use this when you want to allocate by amount rather than usage.

Build Monitors on Usage Metrics and Know the Moment They Spike

The screen and attribution are tools for "reading". To build a mechanism that notices without a person looking, use the usage metrics. Datadog provides the current month's estimated usage in near real time as metrics in the datadog.estimated_usage.* family, and the official documentation lists uses such as graphing them, building monitors with thresholds, and confirming the impact of a code change the same day. The names are fixed by purpose, and the main ones are organized in the table.

Use these names as they are in the monitor's condition expression.

avg:datadog.estimated_usage.metrics.custom{*}
sum:datadog.estimated_usage.logs.ingested_bytes{env:prod}

There is one caveat: these are estimates, and it is stated explicitly that they differ from the values used for billing by 10 to 20% on average, with the error growing larger the smaller the usage. Therefore the use is "detecting change", not "settling the amount". For example, set a threshold on the hourly custom metric count relative to the previous week, or set a ceiling on the daily total of ingested log bytes. When you want to split by team with the .by_tag series, you need to configure the same tag key on the Usage Attribution side (on the Pro plan, a request through your account representative is stated to be required). If you start by creating one monitor each to watch the whole, then clone the Estimated usage dashboard from the dashboard preset list and look at it, the routine starts running before you have memorized all the names.

Check the Four Spike-Prone Cost Items in This Order

When the bill exceeds expectations, the cause is concentrated in an almost fixed set of four cost items: custom metrics, log ingestion, span ingestion, and the number of Synthetics runs. What they share is that "the volume spikes from a single line of code or configuration even if the host count does not change", so an estimate based on host unit prices alone cannot catch them. The order of checking is from the item with the largest swing in amount when it spikes.

The reason custom metrics come first is that the cause tends to be concentrated in "a single metric", and looking at contribution rates in the Top 5000 list lets you identify the offending metric in minutes. Because the number of custom metrics grows with combinations of tag values, attaching just one high-cardinality tag multiplies it by tens. For logs, the order is to look at the breakdown by index to see "which index grew", then narrow it with ingestion controls. Simply looking at the four items in this order twice, at the start and middle of the month, eliminates most month-end surprises. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

Run the "Look-Ahead" Routine Weekly, and Decide Who Looks at What

Even with the mechanisms in place, if the person and frequency are not decided, the bill goes back to where it was. Turning the three places to check covered so far into a routine that continues without strain gives the following form.

The point is to leave daily checks to machines and limit people to weekly. The usage screen lags by up to 72 hours and the estimated metrics have a 10 to 20% error, so having people look at both every day does not improve the accuracy of decisions. Looking only at the difference from the previous week once a week discovers changes sooner with a lighter burden. The other point is to make "being able to state one reason for the increase" the goal. An increase in usage itself may be the healthy result of more monitoring targets. The problem is unexplained increases, and with the Usage Attribution CSV by team you can answer immediately that "the 30% increase since last week is the payments team's new service". When this accountability returns to teams, developers themselves start caring about metric tag design and log levels, and the work of administrators trimming afterward decreases.

How to Use the Figures You Checked - Toward Revising Contract Quantities and Understanding the Pricing Model

Once you can read usage, the next thing that pays off is the shape of the contract. Subscription Details in Plan & Usage lists the quantity, contract unit price, and on-demand unit price for each committed product (as of September 2026, Source: Billing). If the Billable view shows a stable on-demand portion every month, moving that floor to an annual contract lowers the unit price; conversely, if you are well below your committed quantity, that is material for reducing it at the next renewal. For invoice-paid contracts, invoices are delivered to the billing contact registered on the Billing screen (Source: Billing, cited above), so the ideal order is to grasp the current month's trend first through the weekly check at the start of the month, and treat the invoice when it arrives as "confirmation of figures already checked". Checking usage gets faster the better you know which SKU is billed by what unit. The reason custom metrics are counted as "an average count" and logs as "bytes for ingestion, event count for indexing" lies on the pricing model side; the overall picture is covered in How to Decode the Pricing Structure, and the pre-adoption cost-benefit judgment in the Adoption Checklist. If you are not yet on a paid contract, the procedure for taking actual measurements in Free Plan and Trial is also a useful reference.