Time Series Growth Calculator
Project how many new active time series are created per day as pods/services scale, and flag cardinality risk.
Inputs
Net new pods or instances created per day (deployments, autoscaling churn, CI ephemeral environments).
Distinct metric series exposed per pod, including per-pod labels like pod name/instance.
Current total active series count in your TSDB.
Active series count above which you'd expect performance/memory issues on your current setup.
New Active Series per Day
4,800series/day
Cardinality Risk
Low — ample runway at current growth rate
Days Until Warning Threshold
250days
Projected Active Series (30 days)
944,000series
Step by step
New series per day: new pods × metrics/pod
40 × 120
= 4,800 series/day
Projected active series in 30 days
800,000 + 4,800 × 30
= 944,000 series
Days until cardinality warning threshold
(2,000,000 − 800,000) ÷ 4,800
= 250 days
How it works
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
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.