Your observability bill is 25% of infrastructure spend. How do you reduce it without losing the ability to diagnose incidents?

What is being tested

Whether you can reduce cost by removing what is not used rather than by degrading what is.

Where the money is, and the fixes

1. Metric cardinality. Frequently the largest and least understood. Cost scales with unique label combinations, not with traffic, so one unbounded label — a user ID, a request ID, a URL with parameters, an error message string — can multiply the bill and destabilise the backend.

Audit label cardinality, remove unbounded labels, and move that dimension into logs or traces where it belongs. This is usually the single largest saving and it improves stability at the same time, which makes it an easy argument.

2. Log volume and indexing. Indexing is far more expensive than storage, and most logs are never queried. Sample successful requests while keeping 100% of errors and slow requests — and sample by trace, so a kept request retains its whole story rather than a random scattering of lines.

3. Retention, tiered by class. Days hot and searchable, months in cheap object storage queried more slowly. Audit logs on their own long retention; debug logs on days. Uniform retention forces expensive long storage on debug noise.

4. Delete what nobody uses. Most estates emit large numbers of metrics never queried, hold hundreds of dashboards nobody opens, and carry alerts that have never fired usefully. Query the query logs — the tooling knows what is used.

5. Trace sampling with tail-based decisions, keeping all errors and slow requests and a small sample of the rest.

6. Per-host agent licensing, which scales with fleet size rather than with value and may be renegotiable or replaceable with an open collector.

The judgement to state explicitly

Both extremes fail. Cutting observability to save money removes the ability to diagnose incidents, and one longer outage costs more than a year of the tool. Retaining everything forever is a large recurring bill for data nobody reads.

The right frame is per-signal: what question does this answer, and how often is it asked? A signal nobody has queried in six months is a deletion candidate; a signal used in every incident is worth whatever it costs.

What to protect

• 100% of errors and slow requests, in logs and traces. These are what investigations need.
• The golden signals for every service.
• Business metrics, which are frequently the fastest outage detector and are cheap.
• Correlation IDs everywhere, which cost nothing and make everything else usable.

What a strong answer adds

That a cost investigation frequently uncovers personal data, credentials or full request bodies in logs. That is a security finding, and it is usually more urgent than the cost one — and it is a strong additional argument for logging less at the source, which is the cheapest lever of all.