PromQL Query Cost Calculator

Estimate the computational cost of a PromQL query based on range and series selected.

About PromQL Query Cost Calculator

PromQL query cost scales with cost = series_matched × time_range ÷ resolution — the total number of raw samples the query engine must load and process. Memory footprint follows directly: memory = total_samples × bytes_per_sample. Queries that select many series over long ranges at fine resolution (e.g. a broad regex selector over 30 days at 15s resolution) can require gigabytes of transient memory and multi-second execution — recording rules pre-compute these into a much smaller derived series.

Formula

query_cost = series_scanned × time_range_seconds × bytes_per_sample

series_scanned: Number of time series the query touches
time_range_seconds: Duration of the query lookback window (seconds)
bytes_per_sample: Average bytes per data point scanned

Worked example

With the default values below, PromQL Query Cost Calculator returns Query Cost (samples evaluated) of 28,800,000. Change any input above and every figure here is recalculated in your browser.

Inputs used

Series Matched by Selectoraccepts 1–100,000,000 series: 5,000 series
Query Time Rangeaccepts 0.01–87,600 hours: 24 hours
Step / Resolutionaccepts 1–86,400 seconds: 15 seconds
Bytes per Sample (in memory)accepts 1–1,000 bytes: 8 bytes

Results

Query Cost (samples evaluated): 28,800,000
Estimated Query Memory: 219.73 MB
Cost Rating: Moderate — noticeable but usually acceptable
Samples per Series: 5,760.0

Step by step

1Samples per series: time range ÷ resolution= 5760.0 samples
2Total samples evaluated (query cost)= 28,800,000 samples
3Memory footprint: samples × bytes/sample= 219.73MB

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

Why do broad label selectors matter so much for cost?

Series matched multiplies directly into total cost — a selector like `{job="api"}` might match 50 series, while an unscoped `{__name__=~".+"}` could match millions, so tightening selectors is often the single highest-leverage optimization available.

What's the best fix for an expensive, frequently-run query?

Pre-aggregate it into a recording rule that runs once on a schedule and stores the result as a new, much lower-cardinality series — dashboards and alerts then query the cheap pre-computed series instead of re-running the expensive raw computation on every load.

Does resolution/step affect accuracy, not just cost?

Yes — coarser resolution (larger step) reduces cost but can miss short-lived spikes between sampled points; recording rules let you keep high evaluation frequency for accuracy while still making ad-hoc dashboard queries cheap.

Do aggregation functions like `sum()` reduce this cost?

They reduce the *output* series count, but the query engine still has to load and process every input sample before aggregating, so `sum(rate(...))` over many series is not meaningfully cheaper to *evaluate* than the ungrouped query — it just returns less data.