How to Audit Datadog Costs Before Your Next Renewal

A Datadog renewal should not begin with:

“What discount can Procurement negotiate?”

It should begin with a more important question:

“What are we actually consuming, why are we consuming it, what will change during the next contract period, and what should we realistically commit to?”

The distinction matters because a renewal quote is a commercial proposal built on technical consumption.

Infrastructure growth changes monitoring demand. Kubernetes changes container populations. New instrumentation changes metrics and traces. Logging decisions affect ingestion and retention. Applications appear and disappear. OpenTelemetry or telemetry-routing projects can change what reaches Datadog at all.

Procurement eventually sees commercial units.

Engineering creates much of the demand behind them.

A credible Datadog cost audit before renewal has to connect both.

Executive summary

Before renewing Datadog, an organization should be able to answer five questions:

1. What did we buy?
   What products, billing dimensions, commitments and contractual terms actually apply?

2. What did we actually use?
   What does representative billable consumption look like, including normal usage, seasonality, peaks and on-demand consumption?

3. What generated that usage?
   Which applications, services, teams, environments and instrumentation decisions explain material demand?

4. What will change?
   Which architecture, business and platform changes will increase or decrease Datadog consumption during the next contract term?

5. What should we commit to next?
   What do low, base and high demand scenarios imply for the next commercial commitment?

The output should be a Datadog Renewal Evidence Pack that reconciles the contract with historical consumption and converts future engineering plans into a defensible demand forecast.

This is not the same as ordinary cost optimization.

If the primary question is how to reduce unnecessary Datadog telemetry, that belongs in Datadog Bill Too High? 12 Configuration Mistakes That Inflate Observability Costs.

The renewal question is different:

What should the organization commit to next?

What is a Datadog renewal cost audit?

A Datadog renewal cost audit is a structured review of the contractual, usage, telemetry and architecture evidence needed to determine the organization's likely future demand before signing its next Datadog commitment.

An invoice review asks:

What did we pay?

A renewal audit asks:

What should we purchase next, and what evidence supports that decision?

That requires both backward-looking and forward-looking analysis.

Historical usage establishes the baseline.

Telemetry explains the baseline.

Architecture and business plans challenge the baseline.

Forecasting converts those findings into future-demand scenarios.

The commercial decision should come after that work.

1. What did we buy?

The first step is not exporting dashboards.

It is reconstructing the commercial agreement.

Collect the applicable Orders, amendments, commercial schedules, purchasing documentation and other relevant contractual material.

For every material Datadog product, establish:

• the product or service purchased,
• the applicable billing dimension,
• committed quantities,
• negotiated pricing,
• contract start and end dates,
• term structure,
• minimum commitments where applicable,
• treatment of usage above commitment,
• included product allotments,
• credits and promotional terms,
• bundles,
• renewal and notice provisions,
• and customer-specific amendments.

The objective is simple:

know exactly which technical consumption dimensions become commercial exposure.

Public Datadog pricing is not your contract

Datadog publishes product pricing and billing documentation, but its own documentation makes clear that commitments and billing treatment must be reconciled with the customer's agreement. Product allotments can also affect what usage becomes billable.

This matters especially for enterprise agreements.

Never build a renewal model by taking telemetry quantities and multiplying them mechanically by public list prices.

The customer's executed agreement is the primary commercial evidence.

Establish the purchase channel

Also determine how Datadog was purchased.

Depending on the organization, this can involve a direct Datadog agreement, a cloud marketplace transaction, or an authorized reseller or managed service provider.

Cloud marketplace purchasing exists across major providers; for example, Datadog documents purchasing through AWS Marketplace, Azure Marketplace integration and Google Cloud Marketplace. Some marketplace arrangements can also interact with broader cloud commitments or consolidated billing.

Do not assume the same contract documents govern every channel.

Datadog's current public MSA specifically states that services obtained through authorized resellers or managed service providers are subject to separate pass-through terms rather than that MSA.

The renewal team therefore needs to know:

Who are we actually buying from, what documents govern the transaction, and what commercial deadline applies?

Understand the organization topology

Large Datadog estates may contain multiple organizations.

Datadog allows a parent organization to see rolled-up total and billable usage across its organizations, which makes parent-level analysis particularly important when several Datadog organizations share commercial exposure.

Before analyzing individual teams, establish the aggregate position.

Otherwise one organization can appear efficient while another quietly consumes the remaining commitment.

Review renewal provisions early

Datadog's current public MSA contains auto-renewal, non-renewal and pricing-adjustment provisions.

That is useful context.

It is not a substitute for reviewing the agreement that actually governs your organization.

An enterprise Order, negotiated amendment, marketplace agreement, reseller arrangement or other applicable document may change the relevant commercial mechanics.

The rule for the audit should therefore be:

use public Datadog documentation to understand the platform; use your governing agreement to understand your contract.

2. What did we actually use?

Once the contract is understood, reconstruct actual consumption.

Datadog's Plan & Usage tooling distinguishes total usage from billable usage, and its Usage Metering API provides hourly, daily and monthly information across multiple usage dimensions. Datadog currently states that Usage Metering data can be delayed by up to 72 hours and is retained for 15 months.

That gives many organizations enough history to build a meaningful baseline.

But twelve months is not a mandatory rule.

The correct analysis period is the period that best represents the business being renewed.

You need enough history to distinguish:

• normal consumption,
• organic growth,
• seasonality,
• temporary spikes,
• major incidents,
• product launches,
• migrations,
• load testing,
• acquisitions,
• one-off projects,
• and workloads that have already disappeared.

A retailer with a large seasonal peak does not have the same demand profile as a stable internal platform.

A company halfway through a cloud migration should not extrapolate every historical month equally.

Build a normalized baseline

Historical data should become a normalized usage baseline.

That means identifying abnormal or temporary consumption rather than blindly averaging everything.

Examples can include:

• telemetry generated during a one-off migration,
• unusual debugging during a major incident,
• temporary performance testing,
• short-lived projects,
• or workloads already scheduled for retirement.

Do not silently remove those periods.

Document them.

Every normalization adjustment is an assumption that Procurement, Finance and Engineering should be able to challenge.

Separate estimated usage from billable usage

Datadog's Estimated Usage Metrics are designed for near-real-time monitoring, but Datadog explicitly warns that they do not always match billable usage.

Datadog currently reports an average difference of roughly 10–20% between estimated and billable usage, with potentially larger error at low usage volumes.

Estimated usage is excellent for detecting operational changes.

It should not automatically become the renewal baseline.

For financial reconciliation, distinguish:

All usage

from:

Billable usage.

Datadog's Usage Details documentation states that the Billable view shows usage contributing to the final bill and can separate commitment, allotment and on-demand components for supported accounts.

That is much more useful for renewal planning than multiplying an operational dashboard by a list price.

Do not assume every Datadog product is billed the same way

This is one of the most important technical details in the audit.

There is no universal aggregation rule that can be applied across every Datadog product.

Datadog documents different billing calculations for different services. Infrastructure host counts, for example, use a high-water calculation based on the lower 99% of hourly usage. Other products use averages, sums, event counts or other product-specific dimensions.

Custom metrics illustrate why this needs particular care.

Datadog continues to document a model in which billable indexed custom metrics are based on the average number of custom metrics per hour over the month. But Datadog now also offers Metric Name pricing, which instead uses unique metric names and datapoint volume, with billing treatment depending on the applicable contract.

Therefore:

never infer the billing formula from the product name alone.

For every material commercial dimension, establish:

Average usage
What does normal consumption look like?

Peak usage
How high does consumption become, and for how long?

Committed usage
What quantity has been commercially committed?

Allotments
What usage is already included through another subscription?

On-demand usage
Where does billable consumption exceed the relevant commitment or allowance?

These numbers answer different questions.

A short peak should not automatically become a twelve-month commitment.

Persistent on-demand consumption should not automatically be dismissed as noise either.

The pattern needs an explanation.

Reconcile commitment against actual consumption

Once the baseline exists, compare commercial commitment and actual usage for every material billing dimension.

Three patterns deserve immediate investigation.

Commitment consistently above demand

Possible explanations include:

• forecast growth that never happened,
• retired applications,
• lower-than-expected product adoption,
• workloads moved elsewhere,
• or an architecture change after the previous contract was signed.

That does not automatically mean the next commitment should equal today's usage.

It means the gap needs to be explained.

Repeated on-demand consumption

This can indicate:

• genuine business growth,
• new workloads,
• expanded Datadog adoption,
• poor previous forecasting,
• or avoidable telemetry growth.

Again, the commercial number alone cannot tell you which explanation is correct.

Engineering has to explain the demand.

Large but infrequent peaks

A peak can represent:

• seasonality,
• an incident,
• a migration,
• temporary debugging,
• performance testing,
• a deployment problem,
• or genuine recurring capacity.

Treating every peak as permanent can overstate future commitment.

Ignoring predictable peaks can understate it.

The audit needs to establish which is which.

3. What generated that usage?

A renewal model becomes credible when material consumption can be connected to technical demand.

Suppose custom metric consumption increased significantly.

The renewal question is not yet:

“How do we reduce custom metrics?”

It is:

“Which applications and instrumentation changes produced the increase, and will that demand continue next year?”

The same logic applies to logs, traces, hosts, containers and other material Datadog dimensions.

Datadog separately tracks different telemetry and billing dimensions. For example, Log Management distinguishes ingestion and indexed-log usage, while APM billing distinguishes several dimensions including ingested and indexed span consumption.

For renewal purposes, you do not need to reproduce a complete telemetry optimization methodology.

You need to answer:

what produced the material demand, and is that demand expected to continue?

Detailed remediation belongs in Datadog Bill Too High? 12 Configuration Mistakes That Inflate Observability Costs.

Put an owner behind material consumption

A statement such as:

“Custom metrics increased 28%.”

is not sufficient evidence for a future commitment.

The renewal team should know:

• which applications or services drove the increase,
• which environments produced it,
• who owns those workloads,
• whether those workloads will remain,
• and whether further growth is planned.

Datadog's Usage Attribution capability supports breaking supported usage down using configured tag keys and provides monthly and hourly datasets. But Datadog also explicitly notes that some products cannot be attributed this way because their usage cannot be tagged during instrumentation.

Do not invent attribution where the source data does not support it.

If most usage can be mapped confidently and a material portion remains unattributed, report both numbers.

The renewal objective is not perfect cost accounting.

It is:

making sure future demand is explainable and accountable.

For a deeper allocation methodology, shared-cost model and showback/chargeback approach, use Observability FinOps: How to Allocate Costs by Team, Service and Environment.

Purchased does not mean used — and used does not mean valuable

The audit should also distinguish three different questions:

Did we purchase it?

Do teams use it?

Would removing it create operational risk?

These are not equivalent.

A lightly used capability can be essential during serious incidents.

A heavily consumed capability can still be poorly governed.

For material Datadog products, establish:

• which teams use them,
• what workflows depend on them,
• whether adoption is growing or declining,
• whether another platform provides overlapping capability,
• and what operational consequence a reduction would create.

This prevents two opposite mistakes:

renewing shelfware simply because it was purchased previously,

or removing low-frequency capabilities that provide substantial operational value.

Identify unexplained platform overlap

A Datadog renewal should also identify materially overlapping observability spend.

Datadog may coexist with platforms such as Splunk, Elastic, OpenSearch, Dynatrace, cloud-native monitoring, Grafana-based stacks or separate security tooling.

Overlap is not automatically waste.

It can be intentional because of:

• different teams,
• different workloads,
• regulatory requirements,
• specialist capabilities,
• or an ongoing migration.

The renewal question is narrower:

Are we about to make another long-term commitment for capability whose role nobody can explain?

If the answer leads to a serious platform-alternative discussion, move that work into a proper migration or architecture assessment.

A renewal audit should identify the question.

It should not pretend that migration economics can be reduced to Datadog's renewal quote.

4. What will change during the next contract term?

Historical usage is evidence.

It is not the forecast.

A Datadog contract covers future demand, and the architecture creating that demand may change substantially during the contract period.

Review the roadmap with Platform Engineering, Enterprise Architecture and major application owners.

Relevant changes may include:

• Kubernetes expansion or consolidation,
• VM-to-container migration,
• data-center exit,
• cloud migration,
• regional expansion,
• new applications,
• application modernization,
• microservice decomposition,
• serverless adoption,
• OpenTelemetry rollout,
• telemetry pipelines or routing layers,
• acquisitions,
• major product launches,
• AI or LLM workloads,
• security-platform changes,
• legacy-system retirement,
• observability consolidation,
• and applications leaving Datadog.

None of these automatically means higher or lower cost.

They change the forecast assumptions.

Architecture can invalidate the historical baseline

Consider an organization retiring a large VM estate while expanding containerized applications.

A forecast that says:

“Last year's consumption grew 10%, so next year's consumption will grow another 10%.”

misses both changes.

The VM component should be modeled downward.

The containerized environment should be modeled separately according to its expected deployment plan.

The same applies when a telemetry-routing layer is introduced.

If OpenTelemetry collectors or another routing architecture will materially change which data reaches Datadog, historical Datadog ingestion may no longer represent future demand.

This is why architecture is a commercial input.

The FinOps Foundation similarly recommends combining historical usage with planned infrastructure, application and demand changes rather than relying solely on mechanical extrapolation.

5. What should we commit to next?

Once contract evidence, historical usage, technical drivers and future architecture have been established, build the renewal forecast.

Do not try to produce a perfectly precise prediction eighteen or thirty-six months into the future.

Build scenarios.

A practical structure is:

Normalized current demand
+ credible organic growth
+ approved new workloads
± architecture changes
− confirmed workload retirements
− validated optimization impact
= future demand

Then model at least three cases.

Low case

Represents lower plausible demand.

This may include confirmed retirements or reductions that have a credible implementation path.

Base case

Represents the most likely business and architecture plan.

This should normally be the central scenario in the renewal discussion.

High case

Represents plausible additional demand or delayed reductions.

It should capture uncertainty without assuming every possible risk occurs simultaneously.

The objective is not mathematical complexity.

It is to make the assumptions visible.

That is much stronger evidence than:

“We consumed 10,000 units last year, so let's commit to 11,000.”

Forecast and commitment are not the same decision

A forecast estimates expected demand.

A commitment determines how much of that demand the organization is prepared to contract for in advance.

Those are separate decisions.

An organization can reasonably forecast one level of demand while choosing a lower commitment to retain flexibility and accept some on-demand exposure.

Another organization with highly predictable demand may prefer committing closer to its expected baseline.

The correct decision depends on:

• demand predictability,
• product-specific billing mechanics,
• contractual treatment of usage above commitment,
• expected architecture changes,
• and the organization's appetite for commercial risk.

FinOps guidance similarly treats commitment decisions as something that should combine current consumption, future plans and cross-functional input rather than being made independently of Engineering.

The audit therefore does not produce a universal commitment percentage.

It produces evidence good enough that the commitment becomes deliberate.

Do not bank optimization that has not happened

This is one of the easiest ways to under-forecast.

Suppose Engineering believes a telemetry stream could eventually be reduced substantially.

That potential saving should not automatically disappear from the renewal baseline.

Ask:

• Is the change designed?
• Has it been validated?
• Is the telemetry actually unnecessary?
• Do other teams depend on it?
• Is there an implementation owner?
• Is there a realistic delivery date?
• Will the change happen before or early enough in the next contract term?
• What happens if delivery slips?

Only include reductions with credible implementation paths in the base forecast.

Everything else belongs in a scenario.

This avoids making a commercial commitment dependent on engineering savings that currently exist only in a presentation.

Renewal is not a binary choice

The audit should not begin with:

renew Datadog unchanged

versus:

migrate away from Datadog.

Evidence can lead to several outcomes.

Renew largely as-is

Appropriate when current commitments and expected future demand remain aligned and the products continue to provide required value.

Right-size commitments

Appropriate when Datadog remains the right platform but current quantities no longer represent expected demand.

Change product or scope mix

Appropriate when some capabilities should expand, contract or disappear.

Evaluate different commercial flexibility

Potentially appropriate where demand uncertainty is high.

Whether a particular structure is commercially available must be established from the actual proposal and agreement.

Optimize before final commitment

Appropriate where avoidable consumption is material and remediation can realistically affect the next contract period.

Investigate an architecture alternative

Appropriate when the evidence suggests the problem is structural rather than merely a poorly sized contract or inefficient telemetry configuration.

Migration should be the final branch of the decision tree.

Not the first.

The Datadog Renewal Evidence Pack

By the time serious commercial discussions begin, Engineering, FinOps, Finance and Procurement should be working from the same evidence set.

A practical Renewal Evidence Pack contains:

The purpose is not to create a larger spreadsheet.

It is to make every material renewal assumption explainable.

Who should own each part of the audit?

Exact organizational boundaries vary, but the responsibilities normally need to exist somewhere.

Procurement should not have to infer technical demand from invoice totals.

Engineering should not have to infer contractual economics from operational dashboards.

The renewal becomes credible when those views meet.

When should a Datadog renewal audit begin?

There is no universal Datadog rule requiring an audit to begin a specific number of days before renewal.

The correct timing depends on contract complexity, procurement processes and how much technical investigation is required.

But the audit should begin early enough that Engineering still has time to explain anomalies, validate reductions and investigate alternatives.

An illustrative enterprise sequence is:

Approximately 120–180 days before renewal

Establish the evidence base.

Collect contractual documentation, identify billing dimensions, obtain historical usage and identify data gaps.

Approximately 90–120 days before renewal

Explain technical demand.

Investigate major changes, peaks, product utilization and consumption ownership.

Approximately 60–90 days before renewal

Build the forward model.

Incorporate architecture changes, workload additions and retirements, and create low/base/high demand scenarios.

Approximately 30–60 days before renewal

Convert the analysis into a decision.

Select the preferred commitment position, identify unresolved risks and evaluate the commercial proposal against the organization's own demand model.

These ranges are planning guidance.

They are not Datadog contractual requirements.

Actual deadlines must come from the governing agreement and the organization's procurement process.

Why Datadog renewal audits fail

Several recurring mistakes undermine renewal decisions.

Starting when the quote arrives

By then Procurement has a deadline while Engineering may need weeks to explain consumption.

Negotiating invoice totals instead of demand

An invoice tells you what was charged.

It does not tell you why the demand exists or whether it will continue.

Using a single month

One month can be distorted by seasonality, incidents, debugging, launches or migrations.

Confusing estimated and billable usage

Datadog explicitly distinguishes the two.

Assuming every peak is future capacity

Temporary telemetry becomes embedded in the next commitment.

Forecasting without the architecture roadmap

Historical demand is extrapolated even though the workloads producing it are changing.

Failing to establish ownership

The company commits to consumption nobody has validated.

Assuming everything currently purchased is mandatory

Historical entitlement becomes permanent by inertia.

Assuming everything expensive is waste

Operationally valuable telemetry is reduced without understanding its purpose.

Counting theoretical optimization as guaranteed savings

The commercial model assumes engineering changes that may never arrive.

Optimizing only the discount percentage

A better unit rate applied to the wrong quantity can still produce a bad contract.

Treating migration as a negotiation tactic

An alternative platform matters only when its workload scope, migration effort, operating model and risk have been investigated seriously.

The final renewal recommendation should fit on one page

The underlying analysis can be extensive.

The final executive decision should not be.

A CTO, CFO or Procurement Lead should be able to see:

Current contract
What the organization has purchased and through which channel.

Normalized usage
What it actually consumes.

Variance
Where commitment and consumption diverge.

Drivers
What explains significant demand.

Architecture changes
What changes during the next term.

Validated reductions
What can realistically disappear.

Future scenarios
Low, base and high demand.

Recommendation
What should be renewed, at approximately what commitment level, and which assumptions remain risky.

Everything else in the audit exists to make that page defensible.

A strong Datadog renewal position is built before the negotiation

The main conclusion is simple.

A Datadog renewal is not primarily a discount exercise.

It is a demand-modeling exercise that eventually becomes a commercial negotiation.

The organization needs to understand:

what it bought → what it consumed → what generated the consumption → what will change → what it will need next.

Only then does it make sense to decide what should be committed.

That is the difference between negotiating from frustration and negotiating from evidence.

Datadog Cost & Renewal Assessment

SAB Consulting helps organizations prepare Datadog renewals by connecting observability architecture, telemetry consumption and commercial commitments into one decision model.

A Datadog Cost & Renewal Assessment can include:

• contract and usage reconciliation,
• historical billable-usage baseline,
• billing-dimension analysis,
• major demand-driver analysis,
• usage ownership and attribution,
• product-utilization review,
• architecture-roadmap impact,
• realistic pre-renewal optimization opportunities,
• low/base/high demand scenarios,
• overlapping-platform review,
• renewal decision framework,
• and an executive evidence pack for Procurement and leadership.

The objective is not to promise a predetermined savings percentage or negotiation outcome.

It is to determine, with technical and commercial evidence:

what your organization should actually commit to before signing its next Datadog contract.

Samuel Abouelfateh — Founder, SAB Consulting
Datadog Cost Optimization · Observability FinOps · Observability Architecture · Kubernetes · Elasticsearch · OpenSearch · Vendor-Neutral Platform Decisions

FAQ

How should we prepare for a Datadog renewal?

Start by reconciling the current commercial agreement with representative historical billable usage. Then identify what generates material consumption, incorporate planned architecture changes and build low, base and high future-demand scenarios before deciding what to commit to.

How do you audit Datadog costs?

A Datadog cost audit before renewal should examine five evidence areas: contract, actual usage, telemetry drivers, future architecture and forecast demand.

The objective is not simply to explain the previous invoice.

It is to determine what the organization should purchase next.

What Datadog usage data should we collect?

Collect representative billable usage for every material contracted dimension, together with commitment, allotment and on-demand information where available.

Use enough history to identify normal demand, trends, seasonality, peaks and abnormal events.

Datadog's Usage Metering API currently provides hourly, daily and monthly usage and retains data for 15 months.

How much Datadog usage history should we analyze?

There is no universal period.

Twelve months is often useful because it can capture seasonality, but the correct period is one that represents the workloads expected during the next contract term.

Historical usage should be normalized when migrations, incidents or temporary projects materially distort the baseline.

How do we know whether our Datadog commitment is too high?

Compare committed quantities with normalized historical billable usage and forecast future demand.

A persistent gap may indicate excess commitment, but it may also represent planned growth.

The gap needs an engineering explanation before it becomes a commercial conclusion.

How much Datadog should we commit to?

There is no universal percentage.

The commitment should be evaluated against normalized usage, predictable growth, approved projects, workload retirements, validated optimization and uncertainty.

The demand forecast and the commercial commitment should be treated as separate decisions.

Should we optimize Datadog before renewal?

Yes, when avoidable consumption can be changed safely on a realistic timeline.

Do not reduce the base forecast using savings that have not been validated or scheduled.

Potential optimization that may or may not occur belongs in a scenario rather than being treated as guaranteed.

What should Procurement ask Engineering before a Datadog renewal?

Procurement should ask Engineering to explain the normalized usage baseline, important peaks, major telemetry drivers, workload ownership, product dependencies, planned retirements, future architecture and credible optimization assumptions.

That evidence allows Procurement to challenge quantity rather than negotiating only the unit rate.

Who should participate in a Datadog renewal assessment?

The exact organization varies, but the work normally requires technical input from Engineering or Platform, usage and forecasting analysis from FinOps or an equivalent owner, financial validation from Finance, contractual expertise from Procurement or Vendor Management, and a leadership decision on commitment risk.

Should we renew Datadog or investigate an alternative?

A high Datadog cost does not automatically justify migration.

First determine whether the issue comes from an incorrect commitment, unnecessary telemetry, genuine workload growth, duplicated capability or the economics of the platform itself.

A migration assessment becomes appropriate when the evidence suggests a structural platform or operating-model problem that right-sizing and optimization will not adequately address.

Selected references

• Datadog Plan & Usage / Usage Details.
• Datadog Usage Metering API.
• Datadog Estimated Usage Metrics.
• Datadog Usage Attribution.
• Datadog Billing and Product Allotments.
• Datadog Custom Metrics and Metric Name Pricing documentation.
• Datadog Master Subscription Agreement.
• FinOps Foundation Forecasting and Rate Optimization guidance.

Datadog pricing, packaging, billing dimensions, product terminology, allotments and contractual terms can change. Validate renewal assumptions against current Datadog documentation and, above all, the governing commercial agreement applicable to your organization.