Prometheus Cardinality Cost Calculator

Workload preset:

Start with a realistic shape, then replace the sample values with Prometheus or remote-write usage data.

Pricing profile:

Choose the cost model closest to your bill, then edit the rates below.

Active series:

Use prometheus_tsdb_head_series, Grafana/Mimir active series, or a billing export for this scope.

Scrape interval:

Use the dominant scrape interval for these series after relabeling and drops.

seconds

Sampling pressure {{ scrapeIntervalLabel }}

Retention period:

Use the period that actually creates billable storage or Prometheus TSDB disk pressure.

days

Retention window {{ retentionLabel }}

Bytes per sample:

This affects storage footprint and self-hosted storage cost, not active-series list pricing.

bytes/sample

Compression assumption {{ bytesPerSampleLabel }}

Active-series rate:

Use current vendor pricing, a negotiated rate, or an internal showback rate.

$ / 1k series mo

Included series:

Set to 0 for pure usage pricing or internal chargeback.

Storage rate:

Use platform storage cost, managed block storage cost, or an internal blended rate.

$ / GiB mo

Head RAM rate:

Use compute memory cost or internal Prometheus shard chargeback.

$ / GiB mo

Monthly budget cap:

Enter 0 to skip budget variance checks.

$ / mo

High-cardinality metric rows:

Model the likely fan-out behind expensive metrics; rows are ranked in the offender table and chart.

Check cardinality assumptions

{{ error }}

Export label:

Names the estimate in copied summaries, tables, and JSON.

Billing days per month:

Keep 30 for most planning estimates; change for exact billing-month reconciliation.

days

Head memory per series:

Use observed shard memory when possible; this default is intentionally conservative for planning.

KiB / series

Storage replica factor:

Use 1 for a single local Prometheus TSDB; use your managed store or object storage replication factor otherwise.

Fixed monthly cost:

Use 0 when the active-series or resource rates already include platform overhead.

$ / mo

Reduction target: {{ reductionTargetLabel }}

Use the target from Adaptive Metrics, relabeling, metric drops, or recording-rule compaction work.

Monthly series growth: {{ growthLabel }}

Use recent growth from active-series history or planned launch traffic.

Forecast horizon:

Use 3 to 24 months for planning and budget review.

months

Prometheus cardinality cost ledger
Cost item	Estimate	Monthly cost	Detail	Copy
{{ row.item }}	{{ row.estimate }}	{{ row.cost }}	{{ row.detail }}

Prometheus high-cardinality metric offenders
Metric	Series	Highest label	Share	Avoidable cost	Copy
{{ row.metric }}	{{ row.seriesDisplay }}	{{ row.highLabelDisplay }}	{{ row.shareDisplay }}	{{ row.savingsDisplay }}
No valid offender rows are currently parsed.

Prometheus cardinality reduction plan
Finding	Signal	Recommendation	Impact	Copy
{{ row.finding }}	{{ row.signal }}	{{ row.recommendation }}	{{ row.impact }}

{{ promqlArtifact }}

{{ jsonPayload }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Prometheus cardinality is the count of active time series created by metric names and their label combinations. A single counter can be cheap when it has a few stable labels, then become expensive when it carries labels such as route, tenant, pod, worker, user, or span name with many possible values. Each unique combination has to be stored, indexed, scraped or ingested, retained, queried, and sometimes billed as a separate series.

Cost planning for Prometheus therefore needs more than a raw storage estimate. Active series drive head memory and many managed-metrics bills, scrape interval controls sample volume, retention controls stored bytes, and high-cardinality labels can multiply all of those costs before the team notices. A useful review separates total monthly cost from the labels and metrics that are most likely to create waste.

This workflow treats cardinality as an engineering budget. It connects the current active-series count, scrape and retention assumptions, resource or vendor pricing, and suspected label offenders so platform teams can estimate monthly spend, rank risky metrics, and size the savings from relabeling, aggregation, or instrumentation changes.

Prometheus labels fan out into active series, retained samples, and monthly cost. — Labels multiply series first; scrape interval, retention, memory, replication, and pricing turn that series count into cost.

How to Use:

Choose the workload preset closest to the Prometheus tenant, shard, remote-write stream, or managed metrics account you are reviewing.
Enter the current active series from a TSDB metric, vendor billing export, or platform dashboard for the same scope.
Set the scrape interval, retention period, bytes per sample, replication factor, and head-memory estimate that match your environment.
Select a pricing profile, then replace the default rates with your managed active-series price, self-hosted storage and RAM rates, fixed cost, or internal chargeback values.
Paste high-cardinality metric rows in the documented format so each metric can be ranked by likely series fan-out and remediation value.
Use the budget cap, reduction target, growth rate, and forecast horizon to compare current cost, savings potential, and future budget risk.

Interpreting Results:

Cost Ledger separates active-series charges, retained storage, head-memory cost, fixed monthly cost, budget variance, marginal cost per series, and forecasted growth.
Label Offenders ranks metric rows by estimated series count and highlights labels that create the largest removable fan-out.
Reduction Plan translates the reduction target into series avoided and estimated monthly savings so cleanup work can be prioritized.
Offender Series Rank shows which metric families dominate the cardinality review.
Cardinality Cost Curve shows how monthly cost changes as active series grows or shrinks around the current baseline.
PromQL Checks provides query patterns for measuring current series, high-cardinality labels, and offender candidates in Prometheus-style systems.
JSON captures the normalized inputs and calculated outputs for tickets, reviews, and recurring platform reports.

Technical Details:

The estimate starts with active time series, converts them into sample volume with the scrape interval, applies retention and replication to storage, estimates head memory from a per-series memory assumption, and then applies the selected pricing model. Managed billing usually emphasizes active series. Self-hosted planning often emphasizes storage, memory, and fixed cluster cost. A blended model can include both.

Formula Core:

samples_per_second = \frac{active_series}{scrape_interval_seconds}

retained_GiB = \frac{samples_per_second \times retention_days \times 86400 \times bytes_per_sample \times replication_factor}{2^{30}}

monthly_cost = \frac{\max (0, active_series - included_series)}{1000} \times active_series_rate + retained_GiB \times storage_rate + head_memory_GiB \times RAM_rate + fixed_cost

For each offender row, estimated series equals the base series multiplied by the listed label value counts. The largest removable label is the one whose removal would collapse the most duplicate series while preserving the remaining label dimensions.

Accuracy Notes:

Use measured active-series and billing data whenever possible. A sampled dashboard count can differ from monthly billing windows or remote-write accounting.
Bytes per sample varies with label size, chunk compression, scrape interval, compaction, exemplars, histograms, and remote-storage implementation.
Head-memory estimates are planning assumptions, not a substitute for measuring Prometheus process memory and shard pressure.
High-cardinality label cleanup should preserve diagnostic value. Do not remove labels required for alerts, SLOs, routing, or incident response without owner review.
Native histograms, classic histogram buckets, exemplars, and multi-tenant remote write can materially change the series and cost model.

Worked Examples:

Scenario	Input Focus	Planning Readout
Kubernetes API service	850,000 active series, 30-second scrape interval, managed active-series billing.	Checks whether the account stays under budget and which request or pod labels create the biggest cleanup opportunity.
Multi-tenant SaaS	Tenant, route, status, and method labels on hot request metrics.	Ranks tenant and route fan-out before deciding whether to bucket tenants, normalize routes, or export rollups separately.
Self-hosted shard	Retention days, bytes per sample, RAM per series, storage rate, and fixed cluster cost.	Shows whether cost pressure is mainly disk, memory, or fixed overhead rather than vendor active-series pricing.

FAQ:

What is a high-cardinality label?

It is a label with many possible values, such as user ID, session ID, tenant, pod, route, or span name. The risk depends on how that label combines with the rest of the metric labels.

Why does scrape interval matter if billing is based on active series?

Active-series pricing may not change, but scrape interval still changes ingestion rate, storage footprint, query volume, and self-hosted resource pressure.

Should every expensive label be removed?

No. Some labels are worth their cost because they support alerts, routing, ownership, or debugging. Use the ranking to focus review, then decide with the service owner.

Glossary:

Active series: A currently active metric name and full label set combination.
Cardinality: The number of distinct series created by metric and label combinations.
Head memory: Memory used by recently active series and samples before they are fully compacted into long-term blocks.
Retention: The period for which samples are kept in the TSDB or remote storage layer.
Offender row: A metric-level estimate of base series, label value counts, owner, and intended cleanup action.