Tracing Storage Calculator

Estimate storage requirements for distributed tracing spans across a sampling rate.

About Tracing Storage Calculator

Distributed tracing storage depends on how many traces are actually retained after sampling, how many spans each trace contains, and the serialized size of each span: storage_per_day = traces × spans_per_trace × avg_span_bytes × sampling%. Sampling is the dominant lever for controlling cost — most production systems sample well under 100% of traces, since full tracing at high request volumes would be prohibitively expensive to store.

Formula

storage_GB_per_day = traces_per_sec × avg_trace_size_KB × 86400 / (1024 × 1024)

traces_per_sec: Traces ingested per second
avg_trace_size_KB: Average trace size including all spans (KB)

Worked example

With the default values below, Tracing Storage Calculator returns Storage per Day of 7.20. Change any input above and every figure here is recalculated in your browser.

Inputs used

Traces per Dayaccepts 0–1,000,000,000,000 traces/day: 10,000,000 traces/day
Spans per Traceaccepts 1–10,000 spans: 12 spans
Avg Span Sizeaccepts 1–1,000,000 bytes: 600 bytes
Sampling Rateaccepts 0.01–100 %: 10 %

Results

Storage per Day: 7.20 GB/day
Projected Monthly Storage: 216.0 GB/month
Sampled Traces per Day: 1,000,000 traces
Traces Dropped by Sampling: 9,000,000 traces

Step by step

1Sampled traces/day: traces × sampling%= 1,000,000 traces/day
2Sampled spans/day: sampled traces × spans/trace= 12,000,000 spans/day
3Storage/day: spans × avg span bytes= 7.20 GB/day

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

What sampling rate is typical in production?

1-10% head-based sampling is common for high-traffic services, often combined with tail-based sampling that always retains traces with errors or high latency regardless of the base rate.

Why does sampling rate matter more than trace count?

Since storage scales linearly with sampled trace volume, halving the sampling rate roughly halves storage cost — it's usually the cheapest lever to pull before optimizing span size or retention.

How does tail-based sampling change this calculation?

Tail-based sampling makes retention decisions after seeing the full trace (favoring errors/slow requests), so the effective sampling rate can vary by trace characteristics rather than being a flat percentage — model it as a blended average rate for this calculator.

Does span size vary a lot between services?

Yes — spans with rich attributes (SQL queries, HTTP headers, custom tags) can be several KB, while simple internal spans might be under 200 bytes; profile actual span sizes from your tracing backend for accuracy.