Grafana dashboards offer a template variable of type 'Interval'. How do you configure its list of durations and its `auto` entry, how does the selected value reach a panel query, and when should the resolution be a user-visible choice rather than left to the duration Grafana computes for each panel?

## The problem the variable solves Almost every dashboard query contains a duration somewhere: the bucket a group-by rolls into, the window a range function looks back over, the granularity of a SQL time bucket. Grafana can compute a sensible duration *per panel* from that panel's own query options — that is the panel-query macro mechanism (`$__interval`, `$__rate_interval`), and its derivation belongs with panel time-range, max-data-points and min-interval settings. The **Interval template variable** is the other option: a duration a *person* chooses from a drop-down at the top of the dashboard. ## Configuring it Add a variable and set its type to **Interval**. Its "query" is a literal comma-separated list of durations — `1m,5m,10m,30m,1h,6h,1d`. Each entry becomes one option; the list is static, so unlike a Query variable nothing about the data influences what is offered. Optionally enable the **auto** option, which prepends an `auto` entry governed by two settings: - **Step count** — how many buckets the visible range should be divided into. Grafana offers a fixed set of counts (1–5, 10, 20, 30, 40, 50, …). With a 6-hour range and a step count of 30, the raw candidate is 12 minutes. - **Minimum interval** — a floor (default `10s`) the computed value may never fall below, so zooming into a one-minute window does not ask the store for buckets finer than the data exists at. Grafana then rounds the candidate to a friendly duration, and that is the variable's value. Two properties matter. First, the calculation uses only the dashboard time range and the variable's own two settings. Second, the result is **one value shared by every panel**. That is the substantive difference from the panel macro, which each panel derives from its own max data points (defaulting to its rendered pixel width) and can therefore resolve differently on a full-width panel than on a narrow one in the same row. ## How the value reaches a query It interpolates by the name you gave it: `$resolution`, `${resolution}` when it must abut other characters, `[[resolution]]` in the legacy syntax. Because it is a genuine variable rather than a query-time macro, the value also: - appears in the dashboard URL as `var-resolution=5m`, so a shared link, bookmark or snapshot reproduces exactly the resolution the author was looking at; - can be referenced in panel titles, descriptions, text panels and data links, letting a graph state the bucket it is drawing ("errors per $resolution"); - is single-valued — Interval variables are not multi-value, so they cannot drive panel or row repetition and the multi-value formatting options do not apply. ## When a human should own the number Use an Interval variable when the duration is **semantic** rather than cosmetic: - The bucket *is* the business question — "orders per hour", "daily active users". Fitting the bucket to the pixel width silently changes what the number on screen means. - Panels must agree with each other. Cross-panel comparison only holds if both aggregate over the same window; a per-panel computed step lets two panels disagree. - The operator is deliberately trading resolution against query cost. On a large store, letting someone drop from `1m` to `1h` during an incident is a cheap escape hatch. - The view must be reproducible from a link or a screenshot: the chosen value travels in the URL, a pixel-derived one does not. Leave the number to the panel's computed interval when it is pure downsampling — "draw about one point per pixel, don't fetch more than the screen can show". A drop-down there only gives users a control that can make the graph worse. The macro-side decision rule is unchanged and not this leaf's subject: `$__rate_interval` inside rate/increase-style windows, `$__interval` for step and group-by. If you expose an Interval variable, it *substitutes* for one of those in the query; it does not stack with them. ## Failure modes to name - **Hardcoding the duration.** A literal `[5m]` or `date_trunc('hour', …)` is right at one zoom level and misleading at every other — the panel stops responding to the time picker. Either a variable or a macro belongs in that slot. - **Offering options below the collection interval.** A `1s` entry against a source collected every 30s hands users a choice that produces empty buckets. - **Auto with no sensible minimum.** Zooming far in drives the computed value pathologically small: more work, no more information. - **Reusing the query in an alert rule.** Alert rules evaluate outside a dashboard and cannot resolve dashboard template variables, so the window must be written explicitly there. - **Expecting it to repeat panels.** Repetition needs a multi-value variable; an Interval variable is a single duration. ## Interview framing Say what it is (a literal duration list plus an optional auto entry with step count and minimum), how the value travels (interpolates by name, shows up in the URL, one value for the whole dashboard), and then land the judgment: expose it when the window is meaningful or must be identical across panels, and leave it to the panel's own computed interval when it is only about not fetching more points than can be drawn.