Usage-based pricing sounds financially fair: pay for what you use. But for DevOps budgets, the hardest problem is often not fairness. It is that what you “use” is shaped by architecture, telemetry habits, team behavior, incidents, and product growth all at once.
By Frank Song
Software engineer and technology writer covering cloud architecture, observability economics, developer workflow, and operational decision-making.
First published: December 2025
Last updated: December 2025
Article type: Interpretive analysis based on public source material and operator-oriented synthesis
Method: This article is based on public pricing and billing documentation from Datadog, Grafana, and New Relic, plus public FinOps guidance about budgeting and forecasting responsibilities. It does not rely on leaked material, confidential customer budgets, or undisclosed interviews. Any scenarios below are illustrative composites designed to explain common operating patterns, not profiles of any specific company.
Editorial standard: This article is written to distinguish verified source material from interpretation, avoid overstating what one vendor’s pricing model proves about the whole market, and stay within a legally conservative framing.
Why You Can Trust This Article
This piece does not pretend that usage-based pricing is either obviously good or obviously bad.
Instead, it uses primary-source pricing and billing material to show why forecasting gets hard in real environments. Vendor documentation is useful for understanding what gets metered and billed. FinOps guidance is useful for understanding why finance and engineering often struggle to forecast those bills together.
The aim here is practical: to explain why DevOps leaders often discover that “usage-based” is not the same thing as “predictable.”
How This Article Was Reviewed
This article was reviewed against four questions before publication:
- Does it distinguish billing mechanics from budgeting behavior?
- Does it avoid implying that unpredictability means usage-based pricing is automatically wrong?
- Does it avoid implying that one vendor’s meter design represents the entire market?
- Does it stay within practical, non-guaranteed language and avoid procurement, legal, tax, or financial advice?
Executive Summary
- Usage-based pricing is hard to predict for DevOps budgets because the billing units are often downstream of technical behavior, not just downstream of procurement choices.
- New Relic prices around data ingest and optional Advanced Compute Capacity Units (aCCUs) for Intelligent Observability features, including AI-related capabilities.[1][2]
- Grafana increasingly mixes host-hour pricing with separate telemetry charges and now separately budgets AI assistant usage by users or investigations.[3][4]
- Datadog combines host-based, hourly, high-watermark, and volume-based models across different products, with separate billing for logs, indexed logs, spans, sessions, and more.[5][6]
- The real budgeting problem is not only “how much telemetry do we have?” It is “which technical and human behaviors change the bill, how fast, and who is responsible for governing them?”
Who This Article Is / Is Not For
This article is for DevOps leaders, SREs, platform teams, FinOps practitioners, engineering directors, and finance partners trying to understand why observability and infrastructure budgets become difficult to forecast under usage-based pricing.
This article is not for readers looking for a beginner’s glossary of observability pricing, a procurement ranking of vendors, or a simplistic claim that usage-based pricing should always be replaced with fixed subscription pricing.
Why this keeps becoming a budgeting problem
The sales story for usage-based pricing is usually clean.
You only pay for what you use. You avoid buying unused capacity. You scale spend with value.
That sounds rational. In many cases, it is.
The budgeting problem appears one layer lower.
DevOps teams do not consume observability and platform services in the same way that a procurement team consumes office software. Their usage is shaped by deployment frequency, telemetry design, logging volume, cardinality, incident frequency, autoscaling behavior, testing patterns, developer habits, and increasingly AI-assisted workflows.
That means the bill is often governed by a moving system, not a stable seat count.
The original observation at the center of this article is simple: usage-based pricing becomes hard to predict for DevOps budgets when the metered unit is technically precise but organizationally unstable.
What the billing docs actually tell you
If you read official pricing pages closely, the problem becomes easier to see.
New Relic’s pricing page centers around data ingest, while its documentation says Advanced Compute is a separate consumption-based add-on measured in Advanced Compute Capacity Units for Intelligent Observability features.[1][2] That means a team is not only forecasting telemetry volume. It may also need to forecast whether advanced AI or analysis surfaces get used more often.
Grafana’s pricing is also more layered than the phrase “usage-based” suggests. For new Application Observability customers, Grafana documents a host-hour price plus separate telemetry charges for metrics, traces, logs, and profiles.[3] Grafana’s Assistant documentation then adds another budgeting wrinkle: customers are told to review usage dashboards to decide how many users or investigations to budget for.[4]
Datadog shows the problem from a different angle. Its billing docs describe hourly host metering, high-watermark calculations for some plans, hybrid monthly/hourly models, separate charges for ingested and indexed logs, indexed and ingested spans, normalized queries, RUM sessions, and more.[5] Its Bill Overview page also emphasizes usage trends and projected end-of-month costs because the bill is inherently dynamic.[6]
Taken together, these examples point to one bigger pattern:
usage-based pricing is rarely one meter. It is a stack of meters.
That is where budget predictability starts to break.
The real reason forecasts drift
The hard part is not that the unit prices are invisible. Often they are quite public.
The hard part is that the drivers of those units are not fixed.
1. Technical behavior changes the bill faster than procurement does
A budget owner may think they bought “an observability platform.”
In practice, engineering choices determine whether the bill grows through:
- more logs
- more traces
- more active series
- more retained data
- more host-hours
- more sessions
- more AI or compute-intensive analysis
That means budget drift can happen without any new contract event.
A new service launch, a noisier logging policy, higher cardinality metrics, a temporary incident burst, or more aggressive tracing can all move the bill before anyone has “bought” anything new.
And in some environments, AI-driven auto-remediation or investigation workflows may increase background query volume faster than teams expect, especially before usage guardrails are mature.
2. Usage is often mixed with optional premium surfaces
Usage-based pricing used to sound like a pure ingest problem.
That is no longer true.
New Relic’s Advanced Compute and Grafana Assistant are good examples of the new pattern.[2][4] The bill is no longer only about the raw telemetry substrate. It is also about whether the organization starts using premium compute, AI, workflow, or investigation surfaces more actively.
That creates a budgeting problem because those surfaces are often adopted behaviorally, not centrally.
One team begins using a premium AI workflow because it is useful during incidents. Another uses it rarely. A third turns it on but never governs who uses it or how often. By the time finance sees the pattern, it may already be embedded in response habits.
3. Meter logic does not line up neatly with org charts
This is one of the least discussed problems.
Engineering teams own technical levers. Finance owns forecast discipline. Platform teams may own tooling. Security teams may drive logging requirements. Product teams may drive traffic spikes. Incident response may drive bursts of usage.
But the bill lands in one place.
That makes forecasting hard because the people who can change the meters are often not the people who own the budget line. FinOps guidance on the finance persona is useful here: finance teams work with FinOps practitioners to support forecasting, budgeting, showback, chargeback, and vendor invoice management.[7]
In other words, the budget problem is not only metering. It is decision coordination.
Mini-case: the team that budgeted for hosts and forgot behavior
A platform team enters the year expecting a roughly stable observability bill.
Its reasoning seems sound. The host count is not changing dramatically. Major platform purchases are already approved. The vendor relationship looks mature.
Then the bill starts drifting.
Not because the company suddenly doubled infrastructure, but because behavior changed.
A new service family ships with more verbose logs. Tracing expands to support a latency investigation. A few dashboards pull in higher-cardinality metrics than expected. The incident team starts using more premium investigation surfaces during outages. Retention choices stay loose because no one wants to be the first team to reduce them.
The original budget model was built around infrastructure scale.
The real bill was being shaped by operational behavior.
That is the gap many DevOps budgets fall into. They forecast the platform. They do not forecast the ways people will use the platform under pressure.
What NOT To Do / Common Mistake
Do not assume usage-based pricing becomes predictable just because the price per unit is visible.
Do not budget only off host count if your bill is driven by logs, traces, active series, sessions, AI compute, or investigations.
Do not treat one month of “normal” telemetry as a reliable baseline if your platform behavior changes with launches, incidents, experiments, or team adoption.
Do not assume observability pricing is only an engineering problem. Forecasting gets weak when finance, platform, and engineering do not share the same model of what drives spend.
And do not confuse projected end-of-month cost with genuine predictability. A better dashboard can help. It does not fix missing ownership.
A Copyable Reality Check
You can paste this into an internal planning doc exactly as written:
Our usage-based observability bill is not driven only by infrastructure scale. It is also driven by telemetry design, retention choices, incident behavior, and feature adoption.
If we budget only off hosts, we will miss the behavioral drivers.
If we budget only off last month, we will miss the architectural drivers.
If we do not define who owns cost-moving technical decisions, usage-based pricing will keep feeling unpredictable even when the vendor pricing is transparent.
That framing is often enough to improve the quality of the budget conversation immediately.
Why predictability gets worse in mature teams, not better
This sounds backwards, but it is common.
As DevOps and platform teams mature, they often add:
- more environments
- more services
- more telemetry types
- more retention needs
- more security logging
- more workflows that depend on observability
- more AI-powered or advanced analysis features
Each one is rational locally.
Together they make the budget more behavior-sensitive.
That is why mature teams sometimes feel more surprise under usage-based pricing than immature teams. The immature team has fewer meters and less instrumentation. The mature team has more value — and more bill drivers.
Budget Driver Map
A more useful budget review starts by mapping the driver, not just the invoice line.
| Bill driver | Typical technical cause | Typical owner | Review cadence |
|---|---|---|---|
| Logs volume | verbose logging, loose retention, duplicated pipelines | platform + app team | monthly |
| Active series | high-cardinality metrics, instrumentation sprawl | engineering + platform | sprint + monthly |
| Traces volume | tracing expansion, aggressive sampling, new services | platform + service owners | monthly |
| Sessions / user telemetry | product traffic growth, broader frontend instrumentation | product + engineering | monthly |
| AI investigations / advanced compute | incident habits, premium feature adoption, auto-remediation workflows | SRE + platform + finance | monthly |
Start with the top three bill drivers in your environment and review them monthly before expanding the map.
Decision Framework by Stage
The cleanest way to handle usage-based pricing is by stage, not by ideology.
| Stage | What usually hurts first | What you probably need most | What to avoid |
|---|---|---|---|
| Stage 1: Meter visibility is weak | Nobody can explain which unit actually drives the bill | Identify the dominant meter: ingest, series, sessions, host-hours, compute units, or another driver | Forecasting from invoice totals alone |
| Stage 2: Basic growth starts distorting the bill | Logs, traces, or metrics rise faster than infrastructure count | Set default guardrails for retention, cardinality, sampling, and noisy sources | Assuming “more usage” always means “more value” |
| Stage 3: Multi-team adoption begins | Different teams use the same platform in very different ways | Allocate usage by team, service, or environment and define cost ownership | Letting the platform team carry all accountability |
| Stage 4: Premium add-ons and AI surfaces appear | Advanced compute, investigations, or premium workflows create spend drift | Treat AI / advanced compute as a separate budget category, not a hidden add-on | Bundling all spend into one generic observability line |
| Stage 5: Budgets become political | Finance, engineering, and product read the same bill differently | Build a FinOps-style review cadence around usage drivers, forecasts, and trade-offs | Thinking a cheaper unit price solves the governance problem |
The practical point is this: predictability improves when you budget by behavior and ownership, not when you argue abstractly about whether usage-based pricing is good or bad.
What this does not mean
This does not mean usage-based pricing is inherently flawed.
It does not mean fixed pricing automatically solves observability budgeting.
It does not mean every AI or premium feature should be avoided because it can move the bill.
And it does not mean better forecasting depends only on a better vendor contract.
The narrower and more defensible takeaway is this: usage-based pricing becomes hard to forecast when engineering behavior, telemetry design, and budget ownership are not governed with the same level of discipline as the bill itself.
What usually owns what
A useful budgeting model becomes easier once responsibilities are clearer.
- Engineering / Platform usually owns the technical levers: instrumentation patterns, retention, sampling, workload placement, and operational defaults.
- Finance / FinOps usually owns forecasting discipline, invoice interpretation, budget tracking, and variance review.[7]
- Security / Reliability leadership often influences the minimum telemetry floor because risk tolerance affects how much data teams are willing to drop.
- Product / Business leadership often determines how much budget volatility is acceptable in exchange for growth, release speed, customer visibility, or AI feature use.
This is why usage-based pricing becomes hard to predict: the cost units live in the product, but the decision rights live across the organization.
A more useful interpretive model
Think of the forecasting problem this way.
The invoice is downstream of meters
That part is obvious.
The meters are downstream of technical design
That part is less obvious.
The technical design is downstream of operational behavior
That part is what most budgets miss.
Once you see the chain clearly, the unpredictability stops looking mysterious.
It looks organizational.
Observability Budget Predictability Worksheet
Use this as a lightweight planning sheet before the next budget review.
- dominant billing meter identified
- retention policy owner assigned
- cardinality risk reviewed
- premium add-on usage tracked
- AI / advanced compute budget category defined
- forecast owner assigned
- cost-moving technical levers mapped
A worksheet like this is not meant to certify maturity. It is meant to show whether the team is ready to budget from real usage drivers instead of invoice hindsight.
FAQ
Is usage-based pricing inherently bad for DevOps budgets?
No. It can align spend more closely with actual use and can prevent overbuying. The problem is that it often requires better telemetry governance and forecasting discipline than teams initially expect.
Why is observability spend often less predictable than cloud infrastructure spend?
Because observability bills are often shaped by multiple interacting meters — ingest, retention, indexing, sessions, active series, host-hours, or premium compute — and those meters respond quickly to engineering behavior.[1][2][3][4][5]
Does better vendor billing visibility solve the problem?
It helps, but only partially. Datadog’s Bill Overview, for example, improves visibility into usage trends and projected end-of-month cost.[6] That is useful. But visibility is not the same thing as ownership or forecasting discipline.
Do AI features make usage-based pricing more predictable or less predictable?
Usually less predictable at first. They often introduce new billable surfaces — investigations, users, compute units, or advanced feature usage — that teams adopt behaviorally before they govern them properly.[2][4]
Who should own usage-based budget reviews: platform, finance, or engineering?
In most mature organizations, none of those groups can do it well alone. Platform or engineering usually understands the technical drivers, finance understands forecasting and variance, and FinOps or an equivalent shared cadence helps translate usage data into repeatable review decisions. If one team owns the conversation alone, the review usually becomes too technical, too financial, or too reactive.
What is the cleanest budgeting test?
Ask this: if your observability bill jumps next quarter, can you explain whether it came from growth, telemetry design, retention, incidents, team adoption, or premium feature usage? If not, your forecast model is too shallow.
Where the budgeting problem actually starts
The real budgeting problem usually starts at the moment a team still thinks it is buying “a platform” while the vendor is billing a system of behaviors.
That is why the cleanest budgeting move is rarely “negotiate harder” as the first step.
The cleaner first move is to identify which three behaviors most reliably move the bill in your environment and who owns them.
Until that happens, usage-based pricing will continue to feel unpredictable even when the vendor pricing is public and logically consistent.
Next Steps / Related Content
If this article clarified the issue, the next logical questions are:
- Which observability meter actually drives our budget: ingest, active series, sessions, host-hours, or premium compute?
- At what point should AI investigations or advanced compute become their own budget category?
- How should DevOps, platform, finance, and security teams divide cost ownership?
- What guardrails matter first: retention, sampling, cardinality, or adoption control?
Useful published follow-ons from this site include Why Log Ingestion Costs Are Becoming a Bigger Budget Problem, How AI Features Are Reshaping Observability Platform Pricing, and Best Questions to Ask Before Buying an Observability Platform.
About the author
Frank Song is a software engineer and technology writer focused on cloud architecture, observability economics, developer workflow, and operational decision-making. He writes analytical pieces that connect vendor pricing mechanics, FinOps ideas, and practical trade-offs for technical and business leaders.
Editorial standards and update policy
This article is written to an analysis standard rather than a promotional standard. It aims to distinguish verified source material from the author’s interpretation, avoid overstating what one vendor’s pricing model proves about the market, and clearly label practical synthesis versus source-backed billing mechanics.
The article should be updated if major vendors materially revise their usage-based billing models or if new platform features materially change which units become budget-significant.
Source notes
[1] New Relic, Pricing and How New Relic pricing works
[2] New Relic, New Relic Compute
[3] Grafana, Application Observability host-hours pricing and Pricing
[4] Grafana, Understand Grafana Assistant pricing and usage
[5] Datadog, Pricing and Custom Metrics Billing
[6] Datadog, Bill Overview
[7] FinOps Foundation, Finance Persona and FinOps Principles
This article is an original analysis based on those public materials. It does not claim exclusive access to confidential budget data, and it should not be read as legal, tax, financial, or procurement advice.