Observability pricing is no longer just a packaging question. It is becoming a telemetry-governance question.
By Frank Song, a software engineer and tech writer.
Editor’s note: This article is an original evergreen analysis based on public material from Datadog pricing, New Relic’s pricing model documentation, Dynatrace pricing, Elastic’s resource-based pricing overview, Splunk’s observability pricing FAQ, Google Cloud Observability pricing, Grafana Labs’ 2026 Observability Survey, Flexera’s 2025 State of the Cloud report summary, and Gartner’s 2025 public cloud spending forecast. It is not sponsored. The interpretation and conclusions below are the author’s own.
Executive Summary
- More observability vendors are moving toward usage-based billing because modern observability is increasingly tied to data volume, query behavior, and ephemeral infrastructure, not just static hosts.
- This is not only a pricing trend. It reflects how observability itself has changed: more logs, more traces, more teams, more AI-generated telemetry, and more pressure to connect cost with value.
- Vendors are not all using the same unit. Some bill by ingested data, some by users plus data, some by queried data, and some by a mix of host, data, and capability.
- The strategic shift is the same: vendors want pricing that scales with how customers actually consume telemetry, and buyers want pricing that maps more clearly to operational behavior.
Who This Article Is / Is Not For
This article is for engineering leaders, SREs, platform teams, FinOps practitioners, and technical buyers who are trying to understand why observability pricing feels more variable, more data-shaped, and more operationally sensitive than it did a few years ago.
This article is not for readers who want a feature-by-feature vendor comparison, a beginner’s explainer on what observability means, or a simple “cheapest tool” ranking. It is also not written for teams that only need basic infrastructure monitoring and have no near-term plans to scale telemetry volume, retention, or cross-team observability workflows.
The old pricing question in observability was simple: how many hosts do you run?
That question still exists. It is just no longer enough.
Across the market, vendors are quietly telling the same story with different pricing pages. New Relic says its newer primary model bills based on data ingested and number of billable users. Elastic describes its philosophy as pay for the data you use. Dynatrace offers log pricing models such as pay-per-query and retention-based options. Google Cloud Observability prices major products by data volume or usage. Splunk’s own FAQ says usage-based pricing is especially well suited for serverless environments and customers that want granular spend control.
These are not identical models. But they point in the same direction.
The category is moving away from charging mainly for the shape of your infrastructure and toward charging more directly for the shape of your telemetry.
The central observation: observability pricing is being rebuilt around telemetry economics
The more observability becomes a data business, the harder it is to keep pretending pricing should follow hosts.
That is the deeper shift.
Observability vendors used to have an easier time charging around infrastructure surfaces: hosts, agents, nodes, and subscriptions. Those units still exist, and some platforms still use them heavily. Datadog, for example, still shows many product prices in host-, container-, or product-based units. Splunk still offers host-oriented observability pricing in some parts of its portfolio.
But the market is moving because modern software systems no longer behave like tidy, mostly static fleets.
Kubernetes bursts. Serverless workloads do not map cleanly to hosts. AI workloads produce new classes of logs, traces, and event streams. Teams want logs, traces, metrics, profiles, frontend telemetry, and incident context in the same place. And finance wants all of that without a bill that feels disconnected from real operational behavior.
Usage-based billing is the natural answer to that mess.
Not because it is always cheaper. And not because it is automatically simpler. But because it more closely follows where observability cost is actually created.
A simple way to read the pricing shift
| Pricing anchor | What it tracks well | Where it breaks |
|---|---|---|
| Host-based | Stable infrastructure and long-lived workloads | Serverless, bursty containers, short-lived compute |
| Ingest-based | Telemetry volume and storage pressure | Noisy or poorly-governed pipelines |
| Query-based | Actual data usage and analytical intensity | Hard-to-predict query behavior and user habits |
| Hybrid | Mixed environments and broader platform packaging | Becomes harder to explain and forecast |
The point of this table is not to crown a winner. It is to show why the market is fragmenting away from one simple pricing anchor. Choose the model that best matches where your telemetry cost is actually created.
Why vendors are moving this way
There are four main reasons this trend makes sense.
1. Host-based pricing fits modern architectures less cleanly
A lot of observability pricing history came from a world where a company could count servers, attach agents, and buy monitoring accordingly.
That world did not disappear, but it became a much worse proxy.
Serverless, autoscaling containers, short-lived workloads, edge services, and managed cloud services break the neat relationship between “one host” and “one useful unit of observability.” Splunk explicitly says usage-based pricing is well suited for serverless environments or cloud services that don’t provide a view of the underlying hosts. That is the point in one sentence.
If the infrastructure unit is unstable, pricing wants a different anchor.
2. Telemetry volume now drives real cost
Modern observability is not just “monitoring” anymore. It is storage, indexing, query compute, retention, enrichment, correlation, and often AI-assisted workflows on top of all of that data.
Once a platform has to ingest, process, retain, and query massive amounts of logs and traces, charging only by hosts starts to look increasingly disconnected from vendor cost and customer behavior.
Dynatrace’s pricing page makes this visible. Its log analytics models separate ingest, retention, and query. Google Cloud Observability does something similar by pricing core products based on data volume or usage. Those models are not just commercial choices. They reflect the fact that telemetry cost now lives in the data path.
3. Buyers want tighter cost-to-behavior mapping
A lot of teams hate surprise observability bills. But they also increasingly hate pricing models that feel arbitrary.
Usage-based billing gives vendors a way to say: your bill rises because your ingest rose, or your retention grew, or your query volume expanded, or your user footprint changed. That is not the same as saying customers will like the bill. It is saying the bill becomes easier to tie to actual behavior.
That is one reason New Relic’s shift matters. Its current primary model ties cost to ingest and billable users rather than older product-based structures. Whether customers prefer that depends on their workload shape, but the logic is clear: pricing follows how the platform is being used.
4. Vendors want pricing that expands with platform breadth
Observability vendors no longer want to sell one narrow product. They want to sell a platform.
Once the platform includes logs, APM, tracing, RUM, security context, incident workflows, AI assistants, and analytics, the old per-host anchor starts to underprice some customers and overcomplicate others. Usage-based models let vendors capture more of the economic surface of an expanding platform without forcing every capability into the same static license shape.
This is not only about fairness. It is also about monetization discipline.
A harder independent data block: observability pricing is being squeezed by the same pressures squeezing cloud economics
Grafana Labs’ 2026 Observability Survey is useful here. It says the top observability concerns were complexity and overhead (38%), signal-to-noise challenges (34%), and cost (31%).
That already tells you cost has moved into the core of the category.
But the bigger economic backdrop matters too.
Flexera said in its 2025 State of the Cloud reporting that 84% of organizations struggle to manage cloud spend, and that cloud spend was expected to increase by 28% in the coming year. Gartner, separately, forecast worldwide public cloud end-user spending would reach $723.4 billion in 2025, up from $595.7 billion in 2024.
Those figures are not observability-specific, and that is exactly why they matter. Observability is increasingly riding on top of the same cloud cost pressure as everything else. Telemetry is not a side topic anymore. It is part of the cloud finance conversation.
That is the part many pricing discussions miss.
What this does not mean
This does not mean usage-based billing is always better for customers.
It does not mean host-based pricing is obsolete.
And it definitely does not mean every observability vendor is converging on one clean, standard usage model.
In practice, the market is messy.
Some vendors are fully usage-based. Some are hybrid. Some charge by host for some products, by data for others, and by seats or capability units elsewhere. Datadog is a good reminder of this. The platform mixes host-based, product-based, and data-related billing across different modules. Dynatrace gives buyers different log billing models depending on the use case. Splunk continues to blend infrastructure-oriented and usage-oriented approaches. This is not a single-model market.
The better way to read the trend is: more vendors are trying to tie observability pricing to telemetry economics, even if they are doing it in different ways.
When host-based pricing still makes more sense
This trend is real, but it is not universal.
Host-based pricing can still make more sense when your environment is relatively stable, your telemetry profile is predictable, and your team is not yet operating at the point where retention, trace growth, or heavy query behavior dominate the bill.
In practice, that often means:
- long-lived virtual machines or stable host fleets
- low telemetry volatility across weeks or months
- predictable query behavior from a small number of teams
- limited trace adoption and modest retention needs
- a monitoring program that is still closer to infrastructure visibility than telemetry-intensive observability
In those environments, host-based pricing can still be easier to explain internally, easier to forecast, and sometimes operationally calmer than a pure usage-based model.
The mistake is not choosing host-based pricing. The mistake is choosing it after the system has already become telemetry-heavy.
A representative pattern buyers keep running into
This is a representative scenario, not a profile of any single company.
A mid-market engineering team buys an observability platform while its environment is still relatively simple. At first, the spend seems manageable. The team watches core services, some logs, some metrics, and a small amount of trace data.
Then the platform expands.
Kubernetes grows. More services emit more traces. Logging standards improve. Security wants longer retention. Product wants frontend data. Leadership wants better incident reviews. An AI feature launches and starts generating new events at a rate nobody modeled.
The buyer’s first instinct is to blame “vendor pricing.”
Sometimes that is fair. But often the real change is this: the company has moved from paying for monitoring coverage to paying for telemetry behavior.
That is when usage-based pricing becomes operationally meaningful. It forces teams to ask not just what they are collecting, but why they are collecting it, how long they need it, who is querying it, and which data is actually driving decisions.
Pricing model fit worksheet
| If your environment is mostly… | Pricing models to scrutinize first | Main budgeting risk |
|---|---|---|
| Stable long-lived VMs or hosts | Host-based, hybrid | Paying for static coverage you do not fully use |
| Kubernetes-heavy and autoscaling | Ingest-based, hybrid | Telemetry growth outruns governance |
| Serverless-heavy | Usage-based, query-based | Bills spike with bursty execution and logs |
| Multi-team shared telemetry estate | Hybrid, user + data, query-based | Costs become hard to attribute and explain |
By the end of the review, your team should know whether your main cost risk comes from infrastructure shape, telemetry growth, or query behavior.
Pricing model decision tree
Use this as a first-pass decision aid, not as a substitute for a full pricing review.
| Start with this question | If yes | If no |
|---|---|---|
| Is most of your environment built on stable, long-lived hosts or VMs? | Scrutinize host-based or hybrid pricing first. | Move to the next question. |
| Is your main cost risk driven by telemetry growth, retention, or bursty ingest? | Scrutinize ingest-based or hybrid pricing first. | Move to the next question. |
| Is query behavior highly variable across teams or workflows? | Scrutinize query-based pricing first. | Move to the next question. |
| Do multiple teams share the same telemetry estate with different use cases? | Scrutinize hybrid pricing first. | A simpler anchor may still be sufficient. |
A good review should end with one clear answer: is your main observability cost risk created by infrastructure shape, telemetry growth, query behavior, or a mix of all three?
If you are evaluating observability pricing right now, start here
- Identify which signals actually drive incident response, troubleshooting, or business decisions.
- Separate “must retain” telemetry from “nice to have” telemetry.
- Model how costs change if volume doubles, not just if headcount grows.
- Check whether the pricing model matches your architecture: hosts, containers, serverless, or mixed.
- Ask whether the vendor is charging for observability coverage or for observability behavior.
That last question is the important one.
The shift underneath the pricing pages
The old commercial story in observability was: pay for the systems you monitor.
The new story is closer to: pay for the telemetry you generate, retain, and use.
That is a much bigger statement than a pricing-table tweak.
It changes who worries about observability cost. It changes how teams think about retention. It changes whether platform teams optimize for infrastructure coverage or for telemetry discipline. And it changes how observability vendors design products, because the bill is increasingly tied to data behavior rather than static infrastructure shape.
That is why more observability vendors are moving to usage-based billing.
Not because pricing teams suddenly got creative.
Because modern observability is no longer priced around what your systems are. It is increasingly priced around what your systems emit.