Most teams facing an observability budget review reach for the same three or four levers: sample more, retain less, drop some labels, skip indexing on the noisy sources. Under pressure, that instinct makes sense. It's fast, it's within one team's control, and it produces a number finance can see on the next invoice. The trouble is none of those levers work reliably unless they target the part of the bill that's growing. A working strategy for reducing observability cost starts one step earlier: find which charge is driving the invoice, then decide what to change.
Start by finding the charge, not the volume
Every observability platform charges against some dimension: gigabytes ingested, events indexed, query compute, active time series, or hosts reporting in. These charges don't move together. A team can cut total log volume by a third and see almost no change in the bill if the cost driver is a per-event indexing charge, or if cardinality growth in a handful of metrics is quietly consuming the series budget. Cutting retention when the bill is driven by indexing doesn't touch indexing. Cutting hosts when the bill is driven by ingest volume per host doesn't touch ingest.
The first useful step is reading the bill as a set of charges, not a single number. Pull apart what's charged per gigabyte at ingest, what's charged separately for indexing or search, what's charged by distinct series or "cardinality" (the number of unique combinations of a metric's dimensions), and what's charged per host or per agent regardless of volume. Once the dominant charge is identified, the remaining work becomes specific instead of general. A cardinality problem needs a cardinality fix. An ingest problem needs an ingest fix. Conflating them wastes engineering time on the wrong lever.
Why the standard cost levers delete evidence
Most teams reach for four moves under budget pressure: sampling requests down to a fraction of traffic, dropping labels or fields that seem redundant, shortening retention windows, and skipping indexing on lower-priority sources. Each of these is a reasonable, well-understood technique, and each one works in the narrow sense that it lowers next month's invoice.
The tradeoff is that each move also removes evidence before anyone knows whether it will matter. Sampling discards the exact edge cases (rare device and locale combinations, unusual customer paths) that tend to explain the next incident rather than the last one. Sampling can end up costing more than it saves, because a team has to reconstruct what happened from a partial record. Shortened retention removes the baseline a team needs to tell a seasonal pattern from a real regression. Skipped indexing means the data technically exists but isn't searchable when someone needs it during an incident review.
Use these levers as a deliberate tradeoff, not the default response to a rising bill. For metrics specifically, where a single counter can multiply into millions of distinct series once enough dimensions combine, the detailed method for measuring and triaging that growth deserves its own treatment. We've covered the full mechanics in the cardinality playbook for measuring and triaging dimensions rather than repeating it here.
Remove duplication at the collector, not evidence
The more durable move sits earlier in the pipeline, at the collector, before data is billed at all. "Shaping" here means removing duplication and formatting waste, not deciding which evidence matters: duplicate events arriving from redundant agents, the same payload logged twice in different formats, and health-check chatter repeated thousands of times a minute. This is different from sampling. Sampling removes a percentage of everything, including the rare event that matters. Shaping removes repeated copies of data a team already has, while leaving the rest intact.
A useful checklist for this work: look for duplicate events from redundant agents before looking at anything else. Check cardinality limits in the collector and SDKs. They are often wider than the team meant to ship, producing series nobody asked for. Handle high-volume, low-value sources (health checks, verbose framework logs) as a separate stream from low-volume, high-value sources (payment events, authentication failures), so the collector's rules for batching and deduplication match each stream rather than treating all data the same way.
As ingest climbs into tens of petabytes a month, where you filter, batch, and route telemetry is a data-center architecture problem, a shift we describe in moving the shaping work to where telemetry is produced. The sampling and field-dropping many teams reach for is the predictable response to that pressure, and both trade evidence for cost. Moving the shaping work closer to the source is one way to keep more data instead.
Keep the fields you can't predict you'll need
Shaping handles what is clearly duplicated before ingest. A second, related question is what to keep once data is flowing, and the safe default is to keep it. Filtering or dropping fields at ingest is a guess about which questions will matter later, and the questions an incident raises are rarely the ones a team planned for. Customer identifier, route, region, service version, and request ID tend to earn their keep repeatedly, because they're the dimensions teams group by and trace with when isolating impact. Even a field nobody has queried can turn out to be the one that explains the next incident.
Dropping fields is the last lever, not the first. When a team does need to trim, a safer path is to walk through the fields in its highest-volume sources with the people who run investigations, treating query history as one input rather than the answer, since it only describes yesterday's questions. Dimensions that show up in dashboards, monitors, and postmortems stay. For the rest, the better question is whether a pricing model that doesn't charge extra for keeping them removes the need to cut at all. The cardinality playbook covers how cardinality compounds across multiple high-value dimensions.
Choose a pricing model that doesn't charge twice
Even a well-shaped, well-triaged pipeline runs into a ceiling if the pricing model itself charges twice for the same data. Per-series pricing punishes exactly the dimensions a team just decided were worth keeping: the more useful a metric's cardinality, the more it costs, regardless of whether anyone is querying it. Indexing SKUs punish querying data a team already paid to load, since ingest and search are billed as two separate line items. Per-host pricing punishes an architecture decision, charging more for a team that runs many small services instead of fewer large ones, independent of the actual volume produced. This pattern of SKU gating is common across most established observability platforms, where indexing tiers and per-feature add-ons sit on top of the base ingest charge.
These mechanics show up in the market today. Our comparison with Datadog walks through an ingestion charge of roughly $0.10 per gigabyte followed by a separate Standard Indexing charge of about $1.70 per million events at 15-day retention on annual list pricing, meaning a team pays once to load data and again to make it searchable. Unindexed data sits in Live Tail only, not in searchable history.
Our comparison with Splunk describes how license-tier pricing charges on a different basis entirely. Ingest lists at roughly $150 to $225 per GB per day per year, and each SVC (Splunk Virtual Compute) unit runs about $55,000 to $75,000 per year. Many teams respond by leaving entire sources un-onboarded just to stay within budget. Two different vendors, two different charges, the same underlying pattern of a pricing model that charges separately for the visibility a team is trying to preserve. The same dynamic appears in how cost controls quietly reduce what's searchable, since a cheaper log tier is often a different product with its own query capacity and no monitoring support attached.
Our usage-based pricing model is built around a different premise: charge for data loading, query compute, and compressed storage, with a flat platform fee and automatic volume discounts as usage grows, and no second SKU for indexing or a per-series surcharge for cardinality. Everything loaded is queryable without an extra charge to unlock it. We've described our usage-based pricing model in practice: a health tech company sending around 20 terabytes a month, with a year of retention, lands at less than $4,000 per month on Axiom Cloud. That post calls this more than 50% savings versus other vendors, based on our pricing research. That structure also means no surprise bills or overage tier waiting at the top of a usage spike, a point we cover in our recent pricing update.
For teams also weighing the operational side of the ledger, running that infrastructure in-house carries its own cost. The tradeoffs of self-managed and managed alternatives are worth weighing on their own terms before assuming self-hosting is automatically cheaper.
Find the charge, then choose pricing that keeps the evidence
Put together, these moves point in one direction. Identifying the charge behind the bill tells a team where to focus, and shaping at the collector removes duplication without touching the evidence investigations depend on. Past that, cost control comes down to the pricing model. A model that charges separately for indexing or cardinality pushes teams back toward the levers that delete evidence, while one priced on load, query, and storage lets a team keep what investigations might need without cutting data to afford it.
FAQs
Sampling lowers ingest volume, which helps if ingest is the dominant charge on the bill. It does nothing for cardinality-driven cost, since sampled traces can still generate the same number of distinct metric series, and it does nothing for a separate indexing charge. Check which charge is growing before assuming sampling is the fix.
Break the invoice into its component charges: ingest volume, indexing or search charges, distinct time series or cardinality, and host or agent counts. Most vendor billing pages or usage dashboards separate these. Whichever line item has grown fastest relative to actual data volume is the one to target first.
Rarely. Dropping a field at ingest is a guess about which questions will matter later, and the field that looks unused today is often the one an incident needs. Exact duplicates are the safe exception. For anything else, a pricing model that doesn't charge extra to keep the field is usually a better answer than deleting it.
It saves money, but the downside is real: shorter retention removes the historical baseline needed to tell a seasonal pattern from a genuine regression, and it removes the record an incident review needs if the issue surfaces weeks after the event. Retention length should match how far back investigations typically need to look, not the quarter's budget target.
Sampling removes a percentage of everything indiscriminately, including the rare event that would have explained an incident. Shaping removes duplicate events and formatting waste while leaving the rest of the data intact. Shaping targets repetition, sampling targets volume regardless of value.
Because a metric with useful dimensions, like customer ID, region, or route, generates more distinct series than a flat counter, and per-series pricing charges more for exactly that usefulness. Usage-based pricing on load, query, and storage avoids that penalty, since it doesn't bill per distinct series at all.
The distinction is whether the pricing model charges separately for indexing or cardinality on top of ingest. A model priced on load, query compute, and storage can support full retention and full query access without a second SKU gating what's searchable.
Related reading
See how we price for the charges that matter
The fastest way to know whether a pricing change will help is to see it against real usage. Book a demo to walk through how our usage-based pricing applies to your ingest volume, retention needs, and query patterns, with no separate indexing SKU or per-series surcharge to work around.