Metrics Cardinality Calculator
Estimate Prometheus time series cardinality explosion from label combinations, and the resulting storage impact.
Inputs
Number of distinct metric names being emitted (e.g. http_requests_total).
Distinct values for the first label, e.g. 'endpoint' (20 routes).
Distinct values for the second label, e.g. 'status_code' (10 codes).
Distinct values for the third label, e.g. 'pod_name' (50 pods) — often the biggest multiplier.
Approximate memory Prometheus retains per active time series (typically 2-4KB).
Total Active Time Series
500,000
Estimated Memory Footprint
1,525.9MiB
Estimated Memory Footprint
1.490GiB
Series Without Label 3
10,000
Step by step
Total series: base × label1 × label2 × label3
50 × 20 × 10 × 50
= 500,000 series
Series without highest-cardinality label
50 × 20 × 10
= 10,000 series
In-memory footprint
500,000 × 3200 bytes
= 1525.9 MiB
How it works
Prometheus cardinality is the product of every metric name and the distinct values of every label attached to it — adding a label with N distinct values multiplies your series count by N. Formula: total_series = base_metrics × label1_values × label2_values × label3_values. Labels with unbounded or high-cardinality values (pod names, user IDs, request IDs) are the most common cause of cardinality explosions that exhaust Prometheus memory and slow queries.
Formulas
Total time series
total_series = base_metrics × label1_values × label2_values × label3_values
- base_metrics
- Number of distinct metric names
- label1_values
- Cardinality of label 1
- label2_values
- Cardinality of label 2
- label3_values
- Cardinality of label 3
Memory footprint
memory_MiB = total_series × bytes_per_series / (1024 × 1024)
- total_series
- Total active time series count
- bytes_per_series
- In-memory bytes per active series
Frequently Asked Questions
Why is high cardinality a problem?
Each unique label combination creates a new time series that Prometheus must keep in memory and index. Cardinality explosions can consume gigabytes of RAM, slow down queries, and in extreme cases crash the Prometheus process (OOM).
Which labels typically cause explosions?
Labels with values that grow unboundedly or scale with infrastructure churn — pod names, container IDs, user IDs, request IDs, or raw URLs with path parameters — are the usual culprits, unlike bounded labels like status_code or method.
How can I reduce cardinality without losing visibility?
Aggregate high-cardinality labels at collection time, use recording rules to pre-aggregate before long-term storage, or drop/relabel volatile labels (e.g. pod_name) in favor of a stable label like deployment or service.
Is 3-4KB per series accurate?
It's a common rule of thumb for Prometheus's in-memory chunks (varies with churn rate and Prometheus version); use `prometheus_tsdb_head_series` and process memory metrics from your own instance to calibrate a more precise figure.
You might also need
- Prometheus Retention CalculatorCommonly used together
- PromQL Query Cost CalculatorCommonly used together
- Prometheus Storage CalculatorCommonly used together
- Scrape Interval CalculatorCommonly used together
- Prometheus TSDB Size CalculatorCommonly used together
- Metric Ingestion CalculatorCommonly used together