# Template variable > One dashboard layout is right for fifty services, forty hosts, or three environments, and nobody should build it fifty times. - Canonical: https://patterns.konigi.com/dashboards/template-variable - Group: Interaction - Level: flow - Status: published - Updated: September 9, 2026 - Also called: dashboard variable, global filter, environment switcher, scoped dashboard, parameterized dashboard --- ## Problem Operational dashboards are templates by nature. The Kubernetes overview is the same page for every cluster. The service page is the same page for every service. Building one per instance means fifty copies that drift; building one page with a dropdown means one thing to maintain and a dashboard the viewer can point at whatever they're worried about. ## Solution A row of selectors at the top of the dashboard, each bound to a variable that every panel's query references. Change the selector and every panel re-queries. The selectors are populated from the data itself (a query for distinct service names) so the list is never stale. The chosen values live in the URL, which makes a scoped view a shareable link. Bach calls this the parameterized screenspace pattern. In products it's the difference between a dashboard and a dashboard system. ## Use when The same layout applies across many instances of one entity type, and the viewer's first question is "which one?" Clusters, services, hosts, tenants, regions, environments. ## Don't use when The instances need different layouts. A database dashboard and a web-server dashboard share a variable bar but not panels; forcing them into one template gives every viewer half a page of empty panels. Also avoid stacking more than four or five variables; past that, the bar becomes a query builder and belongs in a filter bar pattern with saved views. ## Trade-offs Variables make dashboards abstract. A viewer arriving by link sees "cluster: prod-us-east" and has to notice it before trusting anything below. Multi-select variables produce panels with forty series and no legend that fits. Chained variables (pick a cluster, then a namespace, then a pod) are powerful and slow, and the loading state between selections is where dashboards feel broken. And variables invite the anti-pattern of one giant dashboard for everything, which the collapsible-row pattern then has to rescue. ## Checklist - Is the current selection visible without scrolling, on every screen size? - Are variable values in the URL, so the view can be shared and bookmarked? - What does the dashboard show while a chained variable is reloading? - Is there an "All" option, and does every panel behave sensibly with it? - Does the variable list come from data, and how stale can it get? - When a variable value no longer exists (the pod was deleted), what does the viewer see? - Are panel titles interpolated with the variable so screenshots are self-describing? - Can a panel opt out of a variable, and is that visible? ## Compare **Grafana** is the reference: query, custom, interval, and datasource variables, chaining, multi-select, and the values interpolated into panel titles. **Datadog** does the same with a lighter bar and adds saved views on top of the variable set, which is the right next step. **Netdata** inverts it: instead of a variable, the node and room hierarchy in the left rail is the selector, and every chart is already scoped. **Honeycomb** has no template variables because every view is a query; the "variable" is the WHERE clause, which shows the pattern is a UI over query parameters and can be replaced by one. ## Related Filter bar is what this becomes when the variables are many and arbitrary. Panel grid is what the variables scope. Drill-down is the click that usually sets a variable. Saved view is how teams stop re-selecting the same five values. Overview then detail is the navigation structure variables enable without separate pages. ## Examples ### Grafana (Grafana Labs) The reference implementation for panel grids, template variables, and stat panels; most other tools are defined by how they differ from it. **Examples / Dashboard Variables** — captured September 10, 2026, Grafana Play (signed out; no version string exposed). analytical, medium density, dark theme, desktop-web. Six selectors across the top and the page is unusually honest about what they cost. The middle panel says there is a hidden variable called bestfood, currently set to pizza, which has no control anywhere on screen—state affecting the page that a viewer cannot see or change. The overview panel says that setting Instance and then changing the Prometheus source will clear your selection, because the two variables are chained and the second one invalidates the first. Both of those are correct behaviour and both are the reason parameterised pages get distrusted. What the top row gets right is the display: Instance and CPU Usage Type show their selected values as chips with an × rather than as a count, so what is filtering the page is legible without opening anything. Hotspots in this capture: - [Template variable](https://patterns.konigi.com/dashboards/template-variable) *(this pattern)* — Six selectors bound to every panel's query, with the chosen values carried in the URL. - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — Values as removable chips rather than a dropdown saying Instance (3). - [Explain this metric](https://patterns.konigi.com/dashboards/explain-this-metric) — Names a hidden variable set to pizza. Prose is doing the work a control should. - [Categorical series palette](https://patterns.konigi.com/dashboards/categorical-series-palette) — Twelve-plus hostnames differing only in the middle digits, with twelve-plus colours to match. - [Data table](https://patterns.konigi.com/dashboards/data-table) — Four columns visible, the fourth cut mid-word, with no horizontal scroll offered. ## Related patterns - [Filter bar](https://patterns.konigi.com/dashboards/filter-bar) — The viewer needs to narrow a large set by several attributes and see what's applied. - [Panel grid](https://patterns.konigi.com/dashboards/panel-grid) — Many independent panels need to share one screen without fighting for it. - [Drill-down](https://patterns.konigi.com/dashboards/drill-down) — The overview shows that something is wrong; the viewer needs to get to what, in one click. - [Saved view](https://patterns.konigi.com/dashboards/saved-view) — The team re-selects the same five filters every morning. - [Overview then detail](https://patterns.konigi.com/dashboards/overview-then-detail) — The viewer needs to start wide and end narrow without losing their place. ## Sources - [Grafana, Variables](https://grafana.com/docs/grafana/latest/dashboards/variables/) - [Datadog, Template variables](https://docs.datadoghq.com/dashboards/template_variables/) - [Bach et al., Dashboard Design Patterns—Parameterized](https://dashboarddesignpatterns.github.io/patterns.html) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.