Datadog Cost Review in the 30 Days Before Contract Renewal - A 10-Item Reduction Checklist

Conclusion - run the 30 days before renewal in four checkpoints

If you only start looking at the billing breakdown once the annual renewal date is near, it takes days to spot the items that can be cut, change settings and measure the effect, and turn that into a proposal for committed volumes. This article splits the 30 days before renewal into four checkpoints and fixes only "what to decide" at each. The procedures for checking the numbers are left to Checking Usage and Costs, and how to read the price list to Decoding the Pricing Structure; here we deal only with sequence and judgment. There are two foundational numbers: hourly usage per organization and per product, downloadable as CSV from the Usage Trends screen, and the per-tag breakdown aggregated by Usage Attribution (as of September 2026; source: Usage Details).

There is a single reason for splitting into four: reduction setting changes take days before their effect shows in actuals. If you put log exclusions in place 14 days before, then 7 days before you can back up the reduction amount with a week of actuals. If you touch settings for the first time 7 days before, all you can bring to the renewal date is a projection.

Before cutting, can you name one cause for the spike?

What goes first in the review is not the list of reduction items but a single question. For the months in the past 12 in which the bill grew, can you name the cost line that grew and one cause for it? If you cut committed volumes without being able to, the cause remains and only the overage is billed at the on-demand unit price, creating a path to a bill higher than before from the month after renewal. The Infrastructure Monitoring Pro host unit price differs between the annual contract and on-demand, so this difference applies in full to whatever falls outside the committed volume (source: Datadog Pricing). There are not many candidate causes. It comes down to one of: a change in host count, log index volume, custom metric cardinality, the APM indexing rate, the number of RUM sessions, or the number of Synthetics runs. Pass through this gate before moving on to the next checkpoint. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

30 days before: start by reconciling actuals and taking inventory

There are two things to do at the first checkpoint: reconcile committed volumes against actuals, and take inventory of products. The material is the Usage Trends CSV, in which usage per product is listed hourly for each organization, and the graph display interval can be chosen from day / week / month / year (as of September 2026; source: Usage Details). Color-coding the SKUs that stayed below their committed volume and those that stayed above narrows what you touch at the next checkpoint. In the inventory, look for products whose screens have not been opened once in 12 months, and hosts where the same machine is counted under two names.

Of the three items, the one that matters most in renewal negotiations is the table from item 1. A single line of fact such as "above the committed volume in 9 of 12 months" determines whether the discussion about raising or the discussion about lowering committed volumes should come first.

14 days before: pinpoint five SKUs

At the second checkpoint, you pinpoint the five SKUs whose billing moves in proportion to flow volume and trial setting changes on part of production. The reason for allowing two weeks here is to back up the projected volumes with actuals. The official documentation states explicitly that usage metrics are near-real-time estimates and differ from billable usage by 10 to 20% on average (as of September 2026; source: Estimated Usage Metrics). If you cut committed volumes on projections alone, you will be off by that margin.

If, rather than touching all five items at once, you change them one at a time in order of their effect on the bill and take actuals, then 7 days before you can say separately "what had how much effect." As a rule of thumb for the order, start with the SKUs that had the most months of overage in the 30-days-before reconciliation. The more habitual the overage for a SKU, the more a single setting change alters the committed volume proposal itself.

7 days before: how to write the proposal for resetting committed volumes

At the third checkpoint, you turn committed volumes per SKU into numbers. The skeleton of the proposal is "12 months of actuals minus the expected reduction from the setting changes made 14 days before," treating SKUs with habitual overage and SKUs that are barely used differently. How to read the unit price difference between annual and on-demand, and how overage beyond the committed volume shows up, are covered in Annual Contract vs On-Demand, so here we narrow down to the format of the proposal and the negotiating materials.

There are two reasons for bringing the breakdown. If you can show that the increased usage stems from the expansion of a specific line of business, a proposal to raise committed volumes passes as backing for the business plan rather than as a cost increase. Conversely, if the main driver of growth comes down to one team's configuration, that item should be absorbed by a setting change rather than by committed volume, and can be removed from the proposal. If you negotiate on totals alone without a breakdown, these two cannot be told apart and you are cornered into a binary choice of raising or lowering.

On the day, cross-check the wording of the renewal terms against the proposal

The final checkpoint is the renewal date itself. The job here is not negotiation but verification: cross-check the SKUs, unit prices, and committed volumes listed in the quote against the reset proposal you wrote 7 days before, line by line. There are four points to look at: whether any SKU not in the proposal remains in the quote; whether the units of committed volume (hosts / month, million events / month, and so on) are the same as in the proposal; whether the unit price applied to overage beyond the committed volume is the annual contract price or the on-demand price; and whether the allotments (the per-host inclusions for containers and custom metrics) sit inside or outside the committed volume.

For how to read units and allotments, refer to the "counting rules" in Decoding the Pricing Structure. If a mismatch surfaces during verification, do not move committed volumes on the spot; take only the mismatched lines back and settle them by the next day. Not producing new numbers on the day is the whole point of this 30-day design.

The reduction you must not make is the "make it invisible" type

One idea that always comes up in reduction discussions is to lower the bill by stopping monitoring itself. The three typical forms are uninstalling the Agent, deleting monitors to get rid of alert fatigue along with them, and shortening log retention so drastically that investigation becomes impossible. Each lowers the bill, but in exchange for the amount saved you lose the means to detect and investigate incidents. What you cut in a pre-renewal review is "volume you are watching but not using," not "the means of watching."

The setting changes in items 4 through 8 are all designed to reduce only the counted volume while preserving the visible range. The idea of sequence, make it visible first and then narrow, is covered in the "defensive settings" section of Decoding the Pricing Structure, so it is not repeated here. Once renewal is done, open the same Usage Trends CSV 30 days later and check, line by line, the gap between the projected volumes written in the proposal and the actuals. That gap becomes the first number you look at for the next renewal.