Most platform leaders eventually get asked some version of the same question: how much should observability cost? Finance wants a ratio. Engineering wants a number that reflects what the team needs to stay ahead of incidents. Neither side is wrong to want an answer, but no ratio travels well between organizations. The right diagnostic is whether the bill still buys complete, queryable evidence, or whether sampling, short retention, and indexing SKU gates have already narrowed what the team can ask when it matters.
There is no benchmark percentage worth chasing
Platform teams report very different shares of IT budget for observability. Architecture, retention, and compliance each change the number. A regulated fintech retaining audit trails for years has a different cost profile than a consumer app with a 30-day incident window. A team running thousands of Kubernetes pods generates a different volume of telemetry than one running a handful of long-lived VMs. Comparing their observability spend as a share of infrastructure spend tells us almost nothing about whether either team is well served.
The benchmark question is a distraction from the diagnostic that matters: given this bill, what can the team still ask about its own systems? A team spending less than its peers but retaining full-fidelity data for a useful window is in better shape than a team spending more but sampling away the exact requests that would explain an incident. Spend follows what's kept, not the other way around.
Why observability got expensive and complicated
Teams often notice their observability bill growing faster than the infrastructure it watches, even when traffic hasn't changed. Many pricing models charge on dimensions that multiply independently of request volume, such as number of hosts, number of unique metric series, or gigabytes of indexed log data. Add a new microservice, a new Kubernetes label, or a new OpenTelemetry attribute, and the pricing dimension can grow even though the underlying traffic is flat.
"Cardinality" describes how many unique combinations of dimensions a metric produces. Every unique tag combination becomes its own stored time series, and that series count is exactly the axis some platforms meter. Axiom does not bill on series count, so cardinality never shows up as its own line on the bill. We've written a practical playbook for handling high-cardinality metrics without exploding costs that walks through the mechanism in detail, so we won't retell it here. Modern architectures, wide OpenTelemetry schemas, and per-host or per-series pricing meters can combine to flip the ratio between observability spend and infrastructure spend without anyone changing their traffic pattern at all.
The structural reasons are shared across the industry, not the fault of any single vendor. Microservices multiplied the number of things worth watching. Kubernetes multiplied the number of hosts and short-lived containers emitting telemetry. OpenTelemetry standardized instrumentation but also standardized wide, attribute-rich schemas. A wider schema adds dimensions. It doesn't raise cardinality on its own. Cardinality is how many distinct combinations of values those dimensions produce, and that count is what becomes a separate time series when a platform meters series. Many observability tools responded by charging on the axes that grow fastest under this shift: index volume, series count, per-host fees, or a mix of all three, often bundled into a matrix of SKUs.
That bundling is part of what makes forecasting hard. A bill built from several metered dimensions, each with its own growth curve, is difficult to project even for a team that understands its own traffic well. This is one reason the Axiom vs Splunk comparison describes Splunk's traditional licensing as built around ingest GB per day or workload and service units, sold through a sales process with unpublished list prices. The model itself, not any specific number, is what makes forecasting a negotiation rather than a calculation. Modern observability platforms that gate visibility behind separate indexing tiers add a second layer of complexity, since the team has to track how much data it loaded and how much of that data is searchable.
Does the bill still buy evidence?
A healthy bill, large or small, still buys complete, queryable history. That means no sampling that silently drops the tenant, region, or error class that would turn out to matter in the next incident. We've written before about why sampling can be a costly mistake: the traffic dropped to save money is rarely random, and the moment a team needs the dropped data most is usually the moment it can't get it back.
It also means retention windows that match the business's investigation cycle rather than the platform's default. A customer complaint that surfaces three weeks after the fact is only useful if the underlying request is still there to inspect. On Axiom, longer retention gets cheaper over time: data that goes unqueried moves to lower-cost storage tiers automatically and stays in the same query path. And it means no wall between data that's loaded and data that's queryable. Some platforms load everything but only index a subset for search, a pattern worth naming plainly. The Axiom vs Datadog comparison describes Datadog's Standard Indexing tier as one version of this approach: logs can be ingested broadly but only become searchable once they've been separately indexed, so the loaded volume and the queryable volume end up as two different numbers on the bill. A team evaluating any alternative should ask directly what percentage of loaded data stays queryable and for how long. Our guide to evaluating Datadog alternatives for machine data covers exactly this kind of retention-path scrutiny. A bill can be modest and still fully healthy, or large and already hollowed out by exactly these mechanisms.
Reading your own trend line
A bill growing faster than expected is worth investigating before assuming the growth is inevitable. A bill metered on per-series, per-host, or per-index-GB pricing will often grow faster than the underlying system, because those axes multiply with architectural complexity rather than with retained data volume. That's a symptom of the pricing dial, not a law of telemetry.
A bill that scales with compressed, retained data tends to look different: sub-linear growth as compression improves and volume discounts apply, rather than a step function every time a new service or label gets added. Before concluding that observability spend is out of control, it's worth checking which of these two trend lines the team is on.
What enterprises report spending, and why the number alone doesn't help
Gartner has reported that about 36% of its clients spend more than $1 million a year on observability, about 4% spend more than $10 million, and logs account for more than half of that spend. But those figures don't say what the money bought: how much of that spend went to data that was sampled before it arrived, retained for a week instead of a year, or loaded without being indexed. It wouldn't say what percentage of that spend went to data that was sampled before it arrived, retained for a week instead of a year, or loaded without being indexed. Two enterprises could report the same share of IT budget spent on observability and have completely different amounts of usable evidence behind that number. The ratio describes the size of the check. It says nothing about what the check bought.
How Axiom prices this differently
Axiom's pricing page describes a usage-based dial, with an Always Free allowance, across three components: data loading, query compute, and compressed storage, plus a flat $25-per-month platform fee with no minimum commitment. There's no separate indexing SKU sitting between what's loaded and what's queryable. As Axiom's full access scope through MCP reflects, with no Standard Indexing SKU in the way, every byte loaded is queryable immediately, whether the query comes from a person in Console or an agent through MCP. Volume discounts apply automatically as usage grows, which is part of why our pricing update post frames the model as predictable billing that starts lower and stays lower, with no surprise overage tier partway through the month.
In the comparisons we use in our executive brief, Datadog comes out 15 to 18x higher than Axiom, Splunk Cloud 10 to 12x higher, and Grafana Cloud 4 to 5x higher. Our post on reimagining pricing, using a health-tech workload example, models roughly 20 TB of monthly load, about 8,000 GB-hours of monthly query compute, and twelve months of retention, landing under $4,000 per month on Axiom Cloud. That figure is illustrative and specific to the workload assumptions in that post, not a universal rate card, but it shows what a bill looks like when it's built from retained, compressed data rather than an index or series-count meter. Teams that need SSO, role-based access control, or audit logging can add those through self-serve governance add-ons, priced separately from the core usage dial rather than bundled into it.
Start small without cutting corners
For a small team, observability rarely needs to cost much at all in the beginning. Most early-stage workloads fit comfortably inside a free or near-free tier, and the return on that spend shows up concretely the first time an on-call engineer resolves an incident by querying real data instead of guessing from a dashboard that only shows aggregates. Axiom's Personal tier is free permanently, with 500 GB per month of loading, 10 GB-hours of query compute, 25 GB of storage, and 30-day retention. Axiom Cloud starts with a $25-per-month platform fee plus an Always Free allowance of one TB of load, 100 GB-hours of query, and 100 GB of storage, all detailed on Axiom's pricing page. The payoff is the moment a small team traces a production error to its root cause in minutes rather than reconstructing it from partial logs.
A healthy bill is one you can still query
The right amount to spend on observability is whatever it costs to keep the evidence a team will need, queryable, for as long as the business needs to ask about it.
FAQs
No credible, universally applicable benchmark exists, because retention requirements, architecture, and compliance obligations vary too much between organizations to make a single ratio meaningful. A better question than "what percentage" is whether the team can still query everything it needs to when an incident happens.
This usually happens when pricing meters a dimension that multiplies independently of traffic, such as host count, unique metric series, or indexed log volume. Adding a new microservice, a new Kubernetes label, or a wider OpenTelemetry schema can inflate these dimensions without any real increase in requests served. That's how per-host, per-series, and index-volume meters work. It isn't how Axiom bills. Axiom prices data loading, query compute, and compressed storage, so a new label or a wider schema doesn't open a separate charge.
Check whether sampling is silently dropping data that might matter later, whether retention windows are shorter than the typical investigation cycle, and whether everything loaded is searchable. A modest bill built on complete, queryable, appropriately retained data is healthier than a larger bill undermined by any of those three shortcuts.
It means the volume of data loaded and the volume of data that's searchable can be two different numbers, with a separate fee or tier gating the gap between them. Before adopting any platform, it's worth asking directly what fraction of loaded data ends up queryable and for how long.
Yes. Most early-stage workloads fit comfortably inside a free or near-free tier, and the value shows up the first time an incident gets resolved by querying real data instead of guessing from a partial dashboard.
Axiom prices on data loading, query compute, and compressed storage instead, so cardinality growth or attribute-rich schemas don't independently drive the bill the way they do on per-series or per-host meters. Every byte loaded is immediately queryable, with no separate indexing tier in between.
Axiom's pricing page has a simple calculator for a team's own volume. If a walkthrough would help more than the calculator, our team can do that on a short call.
Related Reading
See what your data costs to keep
The clearest way to answer the spend question is to look at your own logs, traces, and metrics on a usage-based dial instead of an index or series-count meter. Run your volume through the calculator on our pricing page, or start free, and load a real source. If a walkthrough would help, our team can do that on a short call.