Prometheus rate() vs. increase()

rate(http_requests_total[5m]) estimates requests per second over a five-minute lookback. increase(http_requests_total[5m]) estimates the total increase over the same window. For these ordinary counter queries, the latter is the former multiplied by 300 seconds.

Use rate for throughput

rate(http_requests_total[5m])

Prometheus uses samples within the window, adjusts for observed decreases that indicate counter resets, and extrapolates the observed change toward the boundaries. It is more than simply subtracting two endpoint values and dividing by the requested window length.

The result is an average rate over the lookback window, not an instantaneous measurement. It suits throughput charts, rate-based alerts, and recording rules. Longer windows smooth short-lived changes.

Use increase for a window total

increase(http_requests_total[5m])
increase(errors_total[1h])

For a steady estimated rate of two requests per second, the five-minute increase is 600. A real query can return a fractional number even when each observed counter increment is an integer, because the calculation estimates activity at the window boundaries.

Apply the function to each original counter series before summing. Aggregating raw counters first can hide a reset in one instance behind growth in another.

Choose a window with enough samples

For ordinary float counters, at least two usable samples are required. A window of at least four times the scrape interval is a practical starting point that tolerates alignment and some missed scrapes, not a mathematical accuracy guarantee. With a 15-second scrape interval, start at one minute or longer. Grafana's $__rate_interval helps select a suitable rate window when its configured scrape interval matches reality.

Common questions

Why is the increase not an integer? Boundary extrapolation can produce fractions. A longer window may reduce some sampling effects but does not turn monitoring data into exact event accounting. Use durable transactions or events for billing and audit totals.

Are all restarts handled perfectly? No. An observed drop can be adjusted; a reset followed by growth beyond the previous value between scrapes can be invisible. Missing scrapes and newly appearing series also limit what can be inferred.

Can I use these functions on a gauge? They are intended for counters. A float gauge expression may parse, but decreases will have the wrong reset interpretation. Use delta() for gauge change or deriv() for an estimated per-second slope.

References

• PromQL rate and increase functions
• Grafana rate-interval variables