An observability platform can cost less and still be worse for the business.
If a team halves log ingestion but loses the only traces that explain why payment processing is failing, the cheaper dashboard has not improved operations. But if the platform stores millions of repetitive messages that nobody can use to resolve an incident, paying to ingest and retain them is not reliability engineering either.
A useful optimization starts by asking which questions operators must be able to answer.
Start with incident questions, not product names
An SRE team needs to know whether customers are affected, where requests are failing, which change preceded the regression and whether the remediation worked.
Some questions require low-cardinality time-series metrics. Others require detailed logs around a rare failure. A few may need request traces or application profiling. Trying to solve every diagnostic problem with high-cardinality metrics can be expensive and fragile.
The answer is to match signals to tasks and retention requirements. Not everything has to be kept at full granularity forever.
Where the cost actually comes from
A typical observability bill depends on a combination of ingestion, indexing, storage, query resources and retention.
Metrics can expand quickly when labels include volatile values such as request IDs, user identifiers or unbounded URLs. Logs can expand with repeated debug statements, poorly controlled structured fields or high-volume success paths. Query resources can become a bottleneck when dashboards repeatedly scan large intervals.
Before replacing the product, calculate a baseline:
- Samples or events arriving per second and per application.
- Cardinality by metric family and label source.
- Log volume, compression and retention class.
- Query patterns that consume expensive CPU or memory.
- Dashboard and alert rules that teams actually use.
- Costs of collectors, storage, query nodes and supporting infrastructure.
It is common to discover that the data shape matters as much as the software brand.
A real optimization signal
In an anonymous crypto platform engagement, our team replaced parts of a Prometheus/Loki-based observability approach with VictoriaMetrics and VictoriaLogs, along with collector changes using Vector and Victoria tooling.
The owner-reported observability tooling spend fell from approximately $320 per day to $85 per day after the migration and optimization. That is roughly a 73% lower daily tooling cost within the reported cost category.
These are not independently audited statements and are not a universal benchmark of Prometheus versus Victoria. The result was workload-specific. It also belongs within the wider cloud optimization result described in the case-study evidence, not a new percentage to add to a separate overall saving.
The underlying project evidence does not provide a detailed breakdown by software license, VM, disk and data egress line item. We therefore call it observability tooling cost, as the owner described it.
A migration is more than changing storage backends
An observability migration can affect queries, dashboard semantics, retention, labels, alert rules and failure handling.
Even products with compatible query surfaces can have operational differences. A dashboard that renders is not proof that alerts will trigger at the correct moment. A collector that accepts logs is not proof that messages retain their timestamps or labels.
For a team considering a change, an acceptance checklist should include:
- Compare important dashboards against the old system on the same workload.
- Verify that the alerts responsible for customer-impacting incidents still evaluate correctly.
- Check timestamp, label and field mapping through the collection pipeline.
- Simulate collector backlog or storage unavailability and observe data loss/retry behavior.
- Compare cost under comparable ingestion volume and retention settings.
- Keep a rollback route until the necessary incident evidence can be retrieved from the new stack.
Those are recommendations for future migrations, not a claim that every individual check was performed on this account.
Separate log importance from log volume
Not all logs have the same operational value.
An error indicating a failed transaction may be essential. A repeated successful background poll may add little value after aggregate metrics exist. Debug logging might be useful temporarily during a specific investigation, but keeping it on indefinitely can dominate ingestion.
Reducing log volume must be tested carefully: sampling can obscure rare failures, and removing fields can break correlation between services. Define which diagnostic questions must remain answerable, then experiment with filtering, retention and structured fields while watching coverage.
A good result is not "fewer logs." It is "the same or better incident diagnosis for the cost we are willing to carry."
Metrics cardinality needs owners
Metrics often look cheap until each new deployment adds unbounded label combinations.
A request count split by service and response status is usually useful. A metric labeled by a unique session or request ID can create a huge time-series count while answering a question better suited to traces or logs.
SRE teams should monitor high-cardinality series and give application owners clear conventions. That is part of platform governance, not merely a Prometheus tuning exercise.
Measure the cost per useful signal
The cheapest monitoring stack is not automatically the right one.
A practical evaluation includes infrastructure spend, operator time, alert quality, query latency, retention and the ability to diagnose a representative failure. Compare workloads under equivalent data volumes and coverage before attributing a saving to a product migration alone.
For our anonymous project, the reported tooling bill went from about $320/day to $85/day. The figure is useful because it demonstrates that collection and backend choices can matter financially. It does not justify abandoning alerts or diagnostic data to chase another percentage.
Big Bad Byte's cloud cost engineering and DevOps/SRE work treat observability as both an operating capability and a cost center that should be understood.