Getting Observability Costs Under Control

Observability pricing is driven by log volume, custom metric cardinality and host count, all of which grow with engineering activity rather than with business volume. Every new service adds telemetry, and nothing removes it.

The result is a bill that compounds quietly. Unlike compute, nobody notices observability spend until it is compared against the infrastructure it observes.

First, sample traces. Full-fidelity tracing on high-volume services buys little and costs a great deal; head-based sampling with tail-based retention for errors preserves the useful part.

Second, audit metric cardinality. A single label containing user IDs or request paths can multiply a metric's cost by several orders of magnitude, and this is the most common single cause of unexplained increases.

Third, tier log retention. Most logs are never read after seven days. Hot storage for a week and cold archive beyond that typically cuts log spend substantially with no operational loss.

Fourth, drop what nobody queries. Health-check logs, verbose framework output and debug-level noise in production are pure cost.

Fifth, put quotas on teams. Cost that is nobody's budget is nobody's problem; attribution changes behaviour faster than any technical control.

Sixth, review the most expensive dashboards and monitors quarterly. Alerts that nobody has acted on in six months are candidates for deletion, not for tuning.

Reducing spend by removing instrumentation from critical paths is a false economy that gets paid back with interest during the next incident.

The distinction to hold onto is between fidelity and coverage. Sampling reduces fidelity on high-volume paths where statistical signal is sufficient. Removing coverage means being blind somewhere, which is a different and much worse trade.