Count requests over a time period with Prometheus

Use increase(http_requests_total[1h]) to estimate how many requests a counter recorded in the hour before the query's evaluation time. Replace [1h] with [5m] or [1d] for other windows. The calculation adjusts for observed counter decreases and extrapolates from sampled data; it is not an exact transaction count.

Start with one counter series

increase(http_requests_total[5m])  # Previous five minutes.
increase(http_requests_total[1h]) # Previous hour.
increase(http_requests_total[1d]) # Previous 24 hours.

Each distinct label combination returns its own result. increase() estimates a count, while rate() estimates a per-second rate:

For the same window, increase(m[1h]) equals rate(m[1h]) * 3600 under the ordinary counter calculation. Keep the units visible in dashboards.

Combine instances and preserve useful dimensions

sum(increase(http_requests_total[1h]))

sum by (status) (increase(http_requests_total[1h]))

sum(increase(http_requests_total{status=~"5.."}[1h]))

These return, respectively, an overall total, totals by status, and a total for 5xx responses. In a shared Prometheus server, add the job or service selector for the application you intend to measure. Check for duplicate scraping or replicated data before summing.

Always calculate increase() per counter series and then aggregate. Summing first can conceal individual resets.

Why subtracting two values is unreliable

http_requests_total - http_requests_total offset 1h subtracts the selected values at two evaluation times. A reset between them can make the result negative or much too small. The selected samples also need not fall exactly on the requested boundaries.

increase() handles observed decreases and estimates the missing boundary portions. It cannot recover an unseen reset, events between an unobserved reset and the next scrape, or activity before a new series becomes visible. Extrapolation is an estimate, not a guarantee of a closer result for every workload.

Use several scrape intervals in the window; four times the scrape interval is a useful starting point. Sparse samples can yield no result or unstable estimates. Fractional results are expected. Do not apply counter reset semantics to a gauge; consider delta() for that case.

Common questions

Why does the result differ from application records? Check the metric type, scrape gaps, window length, resets, duplicate collection, and aggregation labels. A raw per-instance result is not the service total. Exact accounting belongs in persistent business records.

How do I count requests since midnight? In Grafana, select the desired timezone and a range from today's midnight to now, then evaluate this as an Instant query at the range end:

sum(increase(http_requests_total[$__range]))

A Range query repeats the lookback calculation at each step and produces rolling totals. [1d] means 24 hours, not necessarily a local calendar day around a daylight-saving transition. The result remains an estimate.

Does increase always detect a reset? It detects a visible decrease. A counter that resets and climbs above its previous value before the next scrape can evade that detection.

Related reading

• Count fields in an Elasticsearch index (Chinese)
• Make Chrome trust a localhost certificate (Chinese)

References

• PromQL increase()
• PromQL selectors and evaluation time
• Grafana Prometheus query variables