← All resources
Cloud Platform

The Observability Tax

The cost nobody signed off on: undirected collection is not understanding. Aim it instead.

Executive summary Observability is sold as a pure good: collect everything, you never know what you will need. Followed literally, that advice produces a telemetry bill that can approach, and occasionally exceed, the cost of the systems being observed, while making those systems harder to understand rather than easier. This paper treats observability as a cost with diminishing and eventually negative returns, explains why teams overspend without deciding to, and offers a way to collect less and understand more.

The cost nobody signed off on

Ask a team what their logging and metrics cost and most cannot answer within a factor of two. That is the tell. Observability spend does not arrive as a decision; it accumulates as a habit. Every new service ships with verbose logging on by default. Every incident ends with someone adding more instrumentation so it is never missed again. Every dashboard retains data longer than anyone will look at it. None of these is wrong in isolation, and together they produce a bill that grows faster than the infrastructure it watches, because telemetry volume scales with both traffic and the number of things you decided to record about it.

At scale this becomes absurd in a specific way: you are paying to ingest, index, and retain data about requests, and that cost can rival the cost of serving the requests themselves. You have built a second system, as large as the first, whose only job is to describe the first, and no one ever approved it.

The core idea Observability is not free insurance you collect more of to be safe. It is a cost with a return curve that rises, flattens, and then falls. Past a point, more telemetry does not make the system more understandable. It makes the bill larger and the signal harder to find.

Why more data makes systems harder to understand

The instinct behind overcollection is that more data means more visibility. Beyond a threshold the opposite is true, and this is the part teams miss.

  • Signal drowns in volume. When everything is logged at the same level of importance, the line that would have explained the outage is buried under millions that would not. During an incident, the cost of overcollection is paid in the minutes spent searching, exactly when minutes are most expensive.
  • High-cardinality metrics explode silently. A metric tagged with a user id or a request id generates a distinct series per value, and the cost and query time grow with the cardinality, not the usefulness. Teams add a tag for convenience and quietly multiply their metrics bill by a million.
  • Dashboards become archaeology. A team with two hundred dashboards has, in practice, zero, because no one knows which one to trust. The proliferation that felt like thoroughness produces paralysis.

The uncomfortable truth is that a smaller, deliberately chosen set of signals is not just cheaper. It is more useful, because it is legible.

The distinction that matters Coverage and understanding are not the same thing. Coverage is collecting data about everything. Understanding is being able to answer the questions that matter quickly. Past a threshold they diverge: more coverage buys less understanding, at higher cost.

Where the money actually goes

The bill has three drivers, and they respond to different fixes.

DriverWhy it growsThe lever
Ingest volumeVerbose logging on by default, everywhereLog at the right level; sample high-volume, low-value events
CardinalityMetrics tagged with unbounded values (ids, URLs)Bound label values; move per-entity detail to traces or logs
RetentionEverything kept for the maximum, foreverTier retention by value; keep detail briefly, aggregates longer

Most overspend is concentrated in these three, and most teams have never looked at which one dominates theirs. The first move is not to cut; it is to find out where the money goes, because the three levers are not interchangeable.

Collecting less and understanding more

The goal is not minimal observability. It is deliberate observability: the smallest set of signals that lets you answer the questions you actually ask.

  • Instrument for questions, not for completeness. Start from the questions you need to answer, is the system healthy, is it fast, what broke, and collect what answers them. Data that answers no question you ask is pure cost, however comprehensive it feels.
  • Tier your telemetry by value and life. Not all signals deserve the same retention or fidelity. Keep high-fidelity data for a short window where debugging happens, and aggregates for the long horizon where trends live. Full-fidelity data retained for a year is almost always waste.
  • Sample the high-volume, low-value streams. You do not need every one of a million identical successful requests. You need enough to characterize them and all of the rare failures. Intelligent sampling keeps the signal and drops the redundancy.
  • Control cardinality on purpose. Treat every metric label as a cost decision. Unbounded labels are the single most common cause of a metrics bill that explodes overnight.
  • Prune dashboards and alerts as maintenance. A dashboard no one has opened in a quarter and an alert that only ever fires falsely are both liabilities. Removing them is not neglect; it is hygiene, and it makes the survivors trustworthy.
  • Put a price on the telemetry, visible to the team that emits it. The same accountability that controls compute cost controls telemetry cost. When a team sees what its logging costs, verbose-by-default stops being free.

The reframe

The shift that fixes observability spend is to stop treating telemetry as an asset that is always worth accumulating and start treating it as a cost that must earn its place. An asset you hoard. A cost you justify. The teams that understand their systems best are rarely the ones collecting the most; they are the ones who chose a small set of signals deliberately and can read them quickly, precisely because they are not drowning in the rest.

The takeaway Observability follows a return curve that rises, flattens, and falls, and collect-everything pushes you past the top of it into paying more to understand less. Find where your telemetry money goes across ingest, cardinality, and retention; instrument for the questions you actually ask; tier and sample deliberately; and make the cost visible to the teams that create it. The result is a smaller bill and a system you can actually understand.

Simcha Solutions helps teams right-size observability, cutting the telemetry that only adds cost and keeping the signals that make a system legible under pressure.