Prometheus Cardinality Cost Calculator

Workload preset:

Start from a realistic shape, then replace every sample assumption with values from the same shard, tenant, or remote-write scope.

Pricing profile:

Treat the loaded rates as planning examples until they match your bill, infrastructure model, or internal chargeback.

Active series:

Use prometheus_tsdb_head_series or the equivalent tenant/billing metric.

Scrape interval:

Use the dominant post-relabel scrape interval for this series set.

seconds

Retention period:

Use the local or chargeable remote-store retention window, not a different environment's policy.

days

Bytes per sample:

Replace the planning default with measured TSDB or remote-store compaction data when available.

bytes/sample

Active-series rate:

This is an editable assumption, not a bundled vendor price.

$ / 1k series mo

Included series:

Use zero for pure usage pricing or internal chargeback.

Storage rate:

Use the cost basis for the retained storage represented by this estimate.

$ / GiB mo

Head RAM rate:

Use observed platform cost or a documented internal allocation rate.

$ / GiB mo

Monthly budget cap:

Enter zero to report cost without a budget comparison.

$ / mo

High-cardinality metric rows:

Rows are planning estimates; overlapping metric families are not deduplicated.

Billing days per month:

Use the billing window for sample-volume review; retention is modeled separately.

days

Head memory per series:

Replace the default with observed shard memory divided by a comparable active-series count when possible.

KiB / series

Storage replica factor:

Prometheus local storage is not replicated; keep 1 unless this scope's storage model intentionally multiplies copies.

Fixed monthly cost:

Use zero when the entered usage or resource rates already include platform overhead.

$ / mo

Reduction target:

Validate label use and row overlap before treating the modeled delta as achievable savings.

Isolated series-reduction scenario{{ formatPercent(reduction_target_percent, 0) }}

Monthly series growth:

Use an observed recent rate only when its scope and instrumentation mix remain comparable.

Compound forecast assumption{{ formatPercent(monthly_growth_percent, 0) }} / mo

Forecast horizon:

The curve holds rates, retention, and memory assumptions constant while series count changes.

months

Report label:

This names the audit handoff but does not change the calculation.

Display precision:

Use detailed precision when reviewing small per-series or storage deltas.

Cost item	Estimate	Monthly cost	Review note	Copy
{{ row.item }}	{{ row.estimate }}	{{ row.cost }}	{{ row.note }}

Metric	Series estimate	Highest label	Share	Isolated savings	Owner review	Copy
No offender rows entered. Add metric fan-out rows to rank cleanup candidates.
{{ row.metric }}	{{ formatInteger(row.series) }}	{{ row.high_label }}={{ formatInteger(row.high_label_count) }} · {{ row.risk }}	{{ formatPercent(row.share_pct, percentDigits) }}	{{ formatMoney(row.estimated_monthly_savings_usd, moneyDigits) }}	{{ row.owner }} · {{ row.recommendation }}

Finding	Signal	Recommended review	Modeled impact	Copy
{{ row.finding }}	{{ row.signal }}	{{ row.recommendation }}	{{ row.impact }}

{{ promqlArtifact }}

A metrics bill can jump after a release even when traffic barely moves. The cause is often a new label such as a raw route, tenant ID, pod name, or request identifier. Prometheus creates a separate time series for every unique metric name and label set, so label value counts multiply rather than add.

Consider a histogram with 12 buckets split across 5 methods, 8 status codes, 90 routes, and 16 pods. If every combination exists, that family can produce 691,200 bucket series before the histogram's sum and count series are considered. The individual labels may look reasonable on their own; the product of their value counts is what creates the fan-out.

Active series: Series currently counted for ingestion, memory, capacity, or billing in the selected scope.
Scrape interval: Seconds between samples. Shorter intervals create more samples for every active series.
Retention: How long samples are kept, which directly changes modeled stored volume.
Cardinality: The number of distinct series created by metric names and label combinations.

Cost depends on the commercial and operational model. A managed service may charge per active series, samples, or another contract unit. A self-hosted Prometheus server pays through memory, disk, compute, and engineering effort. A blended internal chargeback can combine both. Rates must therefore come from the actual bill or infrastructure budget rather than from a generic preset.

Reducing cardinality is not the same as deleting useful telemetry. Labels used by alerts, dashboards, routing, and incident investigation may be essential. The better candidates are unbounded identifiers, raw paths, ephemeral worker names, redundant dimensions, and histogram labels whose cost is greater than their diagnostic value. Recording rules, aggregation, route templating, relabeling, sampling, or moving detail to logs and traces can preserve the question while reducing the series count.

Keep every comparison scoped to the same tenant, shard, cluster, or remote-write stream. A fleet-wide offender list paired with a single-shard series count can imply impossible savings. Series estimates for several metric families can also overlap, so their isolated savings should not be added without measuring the combined change.

How to Use This Tool:

Begin with measured active series and rates from one billing or capacity boundary, then test cleanup assumptions against that same boundary.

Choose a Workload preset for a starting shape, then replace Active series, Scrape interval, Retention period, and Bytes per sample with measured values.
Select a Pricing profile. For managed billing, enter the series allowance and rate per 1,000 series-month. For self-hosted or blended planning, enter storage, head-memory, and fixed monthly rates.
Set a Monthly budget cap only when it covers the same scope as the active-series count. A zero cap means no budget comparison is made.
Enter high-cardinality rows as metric | base series | label=value_count, with optional owner and action text. Correct any row named by a validation message before using offender savings.
Set billing days, head memory per series, storage replication, a reduction target, monthly growth, and forecast length in the main form. Use Advanced to change the report label or display precision.
Review total cost, budget status, offender overlap warnings, and the cost forecast together. Recheck the source scope when parsed rows or modeled cost trigger a warning.

Interpreting Results:

Total monthly estimate is the sum of the components enabled by the chosen pricing profile. A managed-series profile can ignore scrape interval in its cost while sample and storage estimates still change.
Budget status is Within budget below the cap, At budget at exact equality, and Over budget above it. With a cap of 0, no budget status is asserted.
Reduction target savings reprices the modeled series count after the chosen percentage reduction. It assumes rates, retention, scrape interval, and resource assumptions remain unchanged.
Each offender's savings is an isolated scenario. Overlapping metric rows or shared labels make those savings non-additive.
A warning appears when parsed offender series exceed 200% of active series or modeled cost exceeds three times the budget. Resolve scope and rate mismatches before using the estimate for a commitment.

Technical Details:

Active series drives the modeled billable-series and head-memory quantities. Sample rate is active series divided by scrape interval, and retained storage grows with sample rate, retention, bytes per sample, and replica count. Prometheus documents 1 to 2 bytes per sample as a rough local-storage planning range, but real footprints can differ with labels, chunks, write-ahead logging, native histograms, exemplars, and remote storage.

Formula Core:

Let N be active series, I scrape interval in seconds, D retention days, B bytes per sample, F storage replica factor, and Q included series.

\begin{array}{ll} S & = \frac{N}{I} \\ V_{month} & = S \times billing days \times 86400 \\ G & = \frac{S \times D \times 86400 \times B \times F}{2^{30}} \\ H & = \frac{N \times KiB per series}{2^{20}} \\ C & = \frac{\max (0, N - Q)}{1000} \times R + G \times P + H \times M + L \end{array}

S is samples per second, V is samples in the billing window, G is retained GiB, and H is head-memory GiB. R, P, M, and L are the active-series, storage, RAM, and fixed monthly rates. Components outside the selected cost model are set to zero.

Transformation Core:

Each offender row converts label-value counts into a series estimate. The base series count is multiplied by every entered label count. The largest count is then removed in isolation to estimate avoidable series and the corresponding monthly cost delta.

N_{metric} = N_{base} \times \prod_{j = 1}^{k} v_{j}

A row with 10 base series, 5 route values, and 2 status values produces 100 estimated series. Removing the largest multiplier leaves 20, so the isolated avoidable estimate is 80 series. This assumes the label dimensions combine fully; sparse combinations will produce fewer real series.

Rule Core:

Prometheus offender risk and forecast rules
Rule	Exact behavior
Unbounded	Highest label count at least 10,000, or an identifier-like name such as request ID, user ID, account ID, tenant ID, trace ID, span ID, session ID, or UUID.
High	Highest label count at least 1,000, or a pod, container, route, path, topic, partition, worker, span, or tenant-like label.
Watch	Highest label count from 200 through 999 when no name rule above applies.
Normal	Highest label count below 200 when no name rule above applies.
Forecast	Series in month m = round(active series × (1 + monthly growth)^m), for 1 through 24 months.

The risk labels and cost profiles are planning heuristics, not Prometheus limits or vendor prices. The highest label is selected by count, with names breaking ties. Managed rates apply per 1,000 billable series-month after the included-series allowance; self-hosted resource rates apply to retained GiB and head-memory GiB.

Accuracy Notes:

This is an editable cost model, not a live Prometheus or billing-system query. Use measurements and rates from the environment being reviewed.

Active-series definitions and billing windows vary across managed services. Match the count and rate to the contract.
Head memory per series is an assumption. Actual memory also depends on labels, chunks, indexes, query load, and churn.
Offender multiplication assumes every label-value combination exists. Confirm candidate savings with TSDB analysis or focused PromQL before changing instrumentation.
Removing labels can break alerts, dashboards, recording rules, routing, or service-level reporting. Review consumers and owners first.

Worked Examples:

Managed series with an allowance

At 100,000 active series with 10,000 included and a rate of 5 per 1,000 series-month, the billable count is 90,000 and the series charge is 450. Adding a fixed monthly cost of 10 gives a 460 total. A 20% reduction removes 20,000 series and models 100 in monthly savings at unchanged rates.

Self-hosted storage sensitivity

For 100,000 series scraped every 15 seconds, 15-day retention and 2 bytes per sample produce about 16.09 GiB of retained samples before other TSDB overhead. The cost effect depends on the entered storage and RAM rates; shortening retention changes storage but not the active-series count.

References:

Data model, Prometheus documentation.
Storage, Prometheus documentation.
Metric and label naming, Prometheus documentation.
How to find high-cardinality metrics in Prometheus, Simplified Guide.
How to analyze Prometheus TSDB blocks, Simplified Guide.