Observability cost optimization: taming metrics, logs, and traces

Quick answer

Observability cost comes from three data types: metrics (often billed per custom metric or time series), logs (per GB ingested and retained), and traces (per span or by sampling volume). Unmanaged, the total can rival compute. Optimize by cutting cardinality and unused custom metrics, setting log retention and sampling high-volume logs, sampling traces intelligently, and matching each signal's retention to its value. The principle is the same across all three: collect what you use, keep it as long as it is useful, and sample the rest.

Observability is essential, and it is also one of the fastest-growing lines on many cloud bills. The reason is that metrics, logs, and traces are billed by volume, and volume grows with every service, every metric, and every request. Left unmanaged, telemetry cost can rival the compute it observes. Optimizing it means being deliberate about what you collect and keep.

The three cost drivers

Signal	Typical billing	Main lever
Metrics	Per custom metric or time series	Cut cardinality and unused metrics
Logs	Per GB ingested and retained	Retention and sampling
Traces	Per span or by sampling rate	Intelligent sampling

Each signal has its own cost driver, so the levers differ, but the theme is constant: you are paying for volume you may not use. The largest single cause of runaway metric cost is cardinality, the explosion of time series when you tag metrics with high-variety labels like user IDs or request IDs, since each unique combination is a separate billable series.

Taming metrics

Audit custom metrics and drop the ones nothing queries or alerts on, since every custom metric is billed. Control cardinality ruthlessly: avoid high-variety labels that multiply time series, and aggregate where you do not need per-instance detail. Many teams collect hundreds of metrics per service and use a fraction, so a cardinality and usage audit is often the biggest single observability saving available.

Taming logs and traces

For logs, follow a proper log retention strategy: expire logs on a schedule, sample high-volume low-value logs, and archive what you must keep to cheap storage. For traces, use intelligent sampling so you keep representative and error traces without paying for every single request. Both signals reward the same discipline: capture the diagnostic value, not every byte, and match retention to how long the data stays useful.

Managed vs self-hosted, and the bigger question

At high volume, weigh managed observability platforms against self-hosted monitoring, since the crossover can be significant. But before switching tools, fix the volume: most observability overspend is collecting and keeping data nobody uses, and no pricing model fixes that. Set retention and sampling as defaults, review usage regularly, and price your observability stack against the resource catalog so telemetry stays a tool, not a runaway cost.

FAQ

Why is observability so expensive?

Because metrics, logs, and traces are billed by volume, and volume grows with every service, metric, and request. Metrics are often billed per custom metric or time series, logs per GB ingested and retained, and traces per span or by sampling volume. Unmanaged, this scales faster than the systems it observes, so telemetry cost can rival the compute it monitors.

What is the biggest observability cost driver?

It varies, but metric cardinality is often the largest and most surprising. When metrics are tagged with high-variety labels like user IDs or request IDs, each unique combination becomes a separate billable time series, so cardinality explodes and cost with it. Auditing custom metrics for cardinality and actual usage is frequently the single biggest observability saving available.

How do I reduce metrics cost?

Audit custom metrics and drop the ones nothing queries or alerts on, since every custom metric is billed. Control cardinality by avoiding high-variety labels that multiply time series, and aggregate where you do not need per-instance detail. Many teams collect hundreds of metrics per service and use a fraction, so a usage and cardinality audit usually yields large savings.

How do I reduce logging and tracing cost?

For logs, set retention periods so they expire on a schedule, sample high-volume low-value logs, and archive what you must keep to cheap storage. For traces, use intelligent sampling that keeps representative and error traces without paying for every request. Both reward the same discipline: capture the diagnostic value rather than every byte, and match retention to how long the data stays useful.

Should I self-host observability to save money?

At high volume, self-hosted monitoring like Prometheus can be cheaper than a managed platform, so it is worth comparing at scale. But most observability overspend comes from collecting and retaining data nobody uses, which no pricing model fixes. Reduce cardinality, retention, and sampling first; then compare managed versus self-hosted for the volume that remains, since the crossover can be significant.

How does C3X help with observability cost?

C3X prices the observability infrastructure in your Terraform, the log storage, monitoring resources, and related services, before you deploy, so a change that would balloon telemetry cost is visible in the pull request. That complements runtime tuning of metrics, logs, and traces by catching the cost of the underlying infrastructure at design time rather than on the monthly bill.

What to do next

Price your observability infrastructure before it ships. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.