Project how the number of active time series will grow as services and labels scale.
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.
projected_series = current_series + new_series_per_month × projection_months
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.
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.
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.
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.