Use the selected Grafana time range in a Prometheus query

Grafana substitutes variables such as $__range before sending a query to Prometheus. These variables are not native PromQL. The query's start, end, and step determine when it is evaluated; a selector such as [1h] determines which earlier samples each evaluation uses.

Use the dashboard's range

For one estimated request total over the selected period, use an Instant query evaluated at the range end:

sum(increase(http_requests_total[$__range]))

A Range query evaluates that same expression repeatedly. At each step it looks backward by the full selected duration, producing rolling increases rather than one fixed-period total. increase() still estimates from sampled counters and cannot provide exact accounting.

Grafana calculates the rate interval as max($__interval + scrape_interval, 4 * scrape_interval). The scrape interval comes from the query's Min step when set, otherwise from the data source's Scrape interval setting. It does not automatically discover every job's true scrape interval. A rate window and a range-query step are different quantities.

Fix a selector's evaluation time

These examples are PromQL after any client variables have been substituted:

http_requests_total[5m]
http_requests_total[5m] @ 1696000000
increase(http_requests_total[1h] @ 1696000000)

The first selects samples in the five minutes before the evaluation time. The second fixes that window's endpoint at a Unix timestamp. The third computes the estimated increase over the hour ending at that timestamp.

A raw range-vector selector is useful in an instant query/table inspection; it is not a valid top-level result for the normal Prometheus range-query API. Apply a suitable function, such as increase(), when you need a graphable instant-vector result at every step.

Avoid common time-range mistakes

A fixed [5m] length still slides as the evaluation timestamp changes. A longer window smooths variation and reads more history; it does not inherently reduce the underlying samples considered. Very short counter windows may contain too few samples. Four scrape intervals is a practical starting point, not an accuracy guarantee.

For an incident from 2 p.m. to 3 p.m., convert the desired date and timezone to the correct Unix timestamp for 3 p.m., then use the fixed one-hour expression. In Grafana, an absolute time-picker range is usually easier. Keep dashboard and panel time overrides in mind.

Common questions

Does $__range work in a Table panel? Yes. Variable substitution belongs to the query, not the visualization. For a single interval summary, select Instant query mode and verify its evaluation timestamp.

Can an alert use dashboard time variables? Alert evaluations run independently of a viewer's dashboard time picker. Use an explicit lookback such as [5m] and the alert rule's own relative time settings; do not copy panel variables into a rule expecting dashboard substitution.

Can I paste the query into Prometheus? Replace Grafana variables with concrete values first, then set the appropriate evaluation time or range parameters.

Related reading

• Use MDC with Java thread pools (Chinese)
• Verify SSL certificates from the command line (Chinese)

References

• Grafana Prometheus template variables
• PromQL time selectors and @ modifier
• Prometheus query API