TelemetryTrim
Observability Cost Savings Calculator
Datadog, Splunk, and friends bill by the gigabyte — see what sampling and shorter retention actually save.
Observability savings from sampling and shorter retention
Logging bills have two parts: ingest, charged once per GB, and storage, charged per GB for every month you keep it. Rows use $0.50/GB ingest and $0.03/GB-month storage against a 13-month baseline.
| Monthly ingest | Kept after sampling | New retention | Baseline | New cost | Monthly saving | Annual |
|---|---|---|---|---|---|---|
| 5,000 GB | 100% | 3 months | $4,450 | $2,950 | $1,500 (33.7%) | $18,000 |
| 5,000 GB | 50% | 3 months | $4,450 | $1,475 | $2,975 (66.9%) | $35,700 |
| 5,000 GB | 50% | 1 month | $4,450 | $1,325 | $3,125 (70.2%) | $37,500 |
| 5,000 GB | 25% | 3 months | $4,450 | $738 | $3,713 (83.4%) | $44,550 |
| 20,000 GB | 30% | 3 months | $17,800 | $3,540 | $14,260 (80.1%) | $171,120 |
The first row changes retention alone and still cuts a third of the bill. Sampling compounds with it because dropping a log saves both its ingest and every month of its storage.
An observability cost savings calculator estimates how much a team can cut from its logging, metrics, and tracing bill by sampling telemetry and shortening data retention. Observability platforms — Datadog, Splunk, New Relic, Grafana Cloud, and the rest — almost all charge by volume: a price per gigabyte ingested and a further price to retain that data over time. For high-traffic systems this bill can run into tens of thousands of dollars a month and is frequently the second- or third-largest line in the cloud budget, yet much of the data is never queried. This tool quantifies the two most effective levers for controlling it.
The model splits observability cost into two parts. Ingest cost is the monthly volume of telemetry multiplied by the platform's per-gigabyte ingest price. Storage cost is that same volume multiplied by how many months it is retained and a per-gigabyte-month storage price. Added together they give the baseline monthly bill. Sampling then reduces the volume that is actually kept — if you keep only half of a noisy log stream, both the ingest and the storage cost of that stream roughly halve. Shortening retention attacks the storage side specifically: keeping data for one month instead of three cuts the storage portion by two-thirds. The calculator applies both changes, recomputes the new monthly cost, and reports the monthly and annual savings along with the percentage reduction, so a platform team can put a dollar figure on a sampling or retention policy before rolling it out.
The important caution, which the source research is careful to make, is that sampling and retention cuts are not free — they trade cost for observability. Aggressively dropping data can leave you blind during an incident, unable to answer a question about a spike that happened three weeks ago, or missing the exact high-cardinality trace that would have explained an outage. The right strategy is almost never a blanket sample rate; it is to cut the low-value, high-volume telemetry hard (verbose debug logs, health-check spam, redundant metrics) while preserving errors, exemplar traces, and the signals your alerts and SLOs depend on. Use this calculator to size the prize, then design a tiered policy that captures most of the savings without sacrificing the data you actually need to run the system. It estimates cost and savings only, using your own per-GB prices — check your provider's specific pricing tiers and commitments for an exact figure.
Ingest vs retention are different levers
Your observability bill has two parts: paying to ingest data and paying to keep it. Sampling reduces both (less data enters the system); shortening retention only reduces storage. If your platform charges mostly on ingest, sampling is the bigger lever; if retention is expensive, cutting how long you keep data matters more. Know which dominates your bill before optimizing.
Cut low-value volume, not signal
The savings are real, but so is the risk of sampling away the one trace or error log you need at 3 a.m. The winning pattern is tiered: drop verbose debug logs, health-check noise, and redundant metrics aggressively, while keeping 100% of errors, exemplar traces, and anything your SLOs and alerts read. A blanket sample rate saves money and hides incidents in equal measure.
Frequently asked questions
We ingest 5,000 GB/month at $0.50/GB with 3-month retention at $0.03/GB-month — what does sampling to 50% and 1-month retention save?
Baseline is $2,500 ingest + $450 storage = $2,950/month. Keeping 50% (2,500 GB) with 1-month retention costs $1,250 + $75 = $1,325/month. That's $1,625 saved a month — about 55% — or roughly $19,500 a year.
Is sampling or shorter retention the bigger win?
It depends on your cost mix. Sampling cuts both ingest and storage, so it usually wins when ingest is the dominant cost (common on per-GB platforms). Shortening retention only touches storage, so it's most powerful when you keep large volumes for a long time. Model both to see which moves your bill more.
Won't sampling hurt my ability to debug incidents?
It can, if done bluntly. The safe approach is tiered: sample or drop high-volume, low-value telemetry (debug logs, health checks) hard, but keep all errors, exemplar traces, and anything your alerts and SLOs depend on. Tail-based sampling that always keeps error traces is far safer than a flat random sample.
How is this different from a cloud storage cost calculator?
A cloud storage calculator prices raw bytes at rest. This one models the observability-specific cost of ingest plus retention and shows the savings from the two policies teams actually use — sampling and retention reduction. It's aimed at the telemetry bill, not general object storage.
Related Developer calculators
Last updated: August 20, 2026