Time Series Growth Calculator
Project how the number of active time series will grow as services and labels scale.
About Time Series Growth Calculator
In dynamic, pod-based environments, active series growth is driven by churn — every new pod instance typically carries its own instance/pod-name label, creating a fresh set of series rather than reusing existing ones: new_series_per_day = new_pods_per_day × metrics_per_pod. Comparing projected growth against a cardinality warning threshold (informed by your TSDB's available memory/CPU) surfaces how much runway remains before series explosion becomes a real operational risk.
Formula
projected_series = current_series + new_series_per_month × projection_months
- current_series
- Current active time series count
- new_series_per_month
- Net new series added per month
- projection_months
- Months to project forward
Worked example
With the default values below, Time Series Growth Calculator returns New Active Series per Day of 4,800. Change any input above and every figure here is recalculated in your browser.
Inputs used
- New Pods/Instances per Dayaccepts 0–1,000,000 pods/day
- 40 pods/day
- Metrics per Podaccepts 1–1,000,000 metrics
- 120 metrics
- Current Active Seriesaccepts 0–1,000,000,000 series
- 800,000 series
- Cardinality Warning Thresholdaccepts 1–1,000,000,000 series
- 2,000,000 series
Results
- New Active Series per Day
- 4,800 series/day
- Cardinality Risk
- Low — ample runway at current growth rate
- Days Until Warning Threshold
- 250 days
- Projected Active Series (30 days)
- 944,000 series
Step by step
- 1New series per day: new pods × metrics/pod= 4,800 series/day
- 2Projected active series in 30 days= 944,000 series
- 3Days until cardinality warning threshold= 250 days
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 whole numbers, 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
Why does pod churn matter more than pod count for cardinality?
Because each new pod instance usually gets a unique name/IP that becomes a label value, high-churn environments (frequent deploys, aggressive autoscaling, CI ephemeral pods) can generate far more distinct series over time than a stable environment with the same steady-state pod count.
How do I reduce new-series-per-day without losing visibility?
Avoid putting high-cardinality, churn-prone values (pod name, container ID, request ID) directly into metric labels where a lower-cardinality label (deployment name, node name) would answer the same operational question.
What happens when I cross the cardinality threshold?
Symptoms include growing Prometheus memory usage, slower query performance (especially for queries spanning many series), longer compaction times, and eventually OOM crashes if left unaddressed — the threshold should be set based on observed memory headroom, not an arbitrary number.
Does deleting old pods reduce active series immediately?
Series for terminated pods become 'stale' and are marked as such after the staleness window (default 5 minutes of no new samples), but they still occupy TSDB space until the retention period passes and the block is compacted away.