Grafana dashboard variables: when one dashboard should serve many hosts
Dashboard variables are named placeholders that a dashboard reads at query time, and repeating panels are panels that Grafana generates once per value of a chosen variable. Together they let one dashboard serve every host, service or environment that shares the same shape of data, instead of a copied dashboard for each one. Teams usually reach for them when the same set of panels has been duplicated, edited separately and drifted apart, so a fix to CPU panels on one copy never reaches the others. The key decision is which variable drives the repetition, because that choice determines how the dashboard scales as your fleet grows.
A query variable is the usual driver for repeating. Its values come from a data source query, such as a list of hosts or services returned by your metrics or logs store, so the dashboard adds or removes panels as that inventory changes. A custom variable is the better fit when the list is fixed and known in advance, such as production, staging and development. The open-source edition supports both patterns, including repeating panels, without an Enterprise license. Confirm the exact variable types and repeat options in your Grafana version's documentation, because the editor labels and defaults have changed across releases.
Before you build, check three things with your team: how many values the variable can return in your largest environment, whether the underlying query is cheap enough to run every time the dashboard loads, and whether the data source can filter by the variable without a full scan. A variable that returns hundreds of hosts can turn one dashboard view into hundreds of queries. Treat the variable design as part of the capacity plan for your data sources, not only as a layout choice.
Which of the eight variable types fits each job
This table compares the eight Grafana variable types by what each is for, when it fits and its main trade-off. Read it by starting from the job the dashboard needs to do, then check the trade-off column before choosing a type, especially where a variable depends on a data source or affects shared URLs.
| Variable type | What it is for | When it fits | Main trade-off |
|---|---|---|---|
| Query | Populates options from a query against a connected data source | Listing hosts, services or regions that already exist in your metrics or logs | Depends on the data source being reachable and on query cost; values change as the data changes |
| Custom | Holds a fixed, manually typed list of values | Small, stable sets such as environments (production, staging) or severity levels | Values must be maintained by hand, so the list drifts from reality over time |
| Text box | Accepts free text typed by the viewer | Filtering on a value no list can anticipate, such as a request ID or ticket number | Viewers can type anything, so queries must handle empty or malformed input |
| Constant | Stores a fixed value referenced by queries and panels | Hiding internal hostnames, paths or identifiers that should not appear in shared links | Hidden from URLs by default, so engineers may not see it when troubleshooting a shared link |
| Data source | Lets viewers switch between data sources of the same type | Dashboards that must run against production or a second cluster with the same metric names | Only lists data sources of one type, and panels must still share compatible queries |
| Interval | Sets a time grouping interval for queries | Controlling resolution so long time ranges stay readable and do not overload the data source | Coarser intervals can hide short spikes, so set limits with the people who read the charts |
| Filters | Builds label or key-value filters applied to queries | Narrowing many series by several labels, such as region plus service, without writing query logic | Works only with data sources that support ad hoc filters; confirm support for each source |
| Switch | Toggles a value on or off for conditional display | Showing or hiding optional panels, rows or query sections for different audiences | Adds branches to the dashboard, so test each state before publishing |
How chained variables narrow choices from one level to the next
A chained variable is one whose query refers to another variable, so each choice narrows the options available at the next level. In a typical layout, a region variable feeds a hosts variable, and the hosts variable feeds a services variable. Grafana resolves variables in dependency order: it evaluates the region first, substitutes the selected value into the hosts query, then evaluates the services query using the selected host. Because the order follows the references in the queries, a level that depends on a variable not yet defined will return empty or stale options. Before adding a level, confirm the variable list on the dashboard settings page shows the upstream variable first and that the downstream query uses its $region or $host reference exactly as named.
Broad upstream queries are the most common cause of slow dashboards with chained variables. A hosts query that lists every host in the metrics store, with no filter on the selected region, forces the data source to return far more series than the user needs, and every change upstream repeats that work. Narrow each query with the labels or fields it actually needs, and keep the number of values small enough for a dropdown to be useful. Check how long each variable query takes against your own data source and volume, since the cost depends on your label cardinality, and ask your data source team which label filters are indexed.
Test each level in isolation before building the next. Set the upstream variable to a single known value, confirm the downstream dropdown lists only the expected entries, and then check that a panel using the downstream variable returns data. Use the variable refresh setting deliberately: refreshing on dashboard load suits values that change often, while refreshing only on time range change reduces query load for slower-moving lists. Repeat the test with an empty or All selection, since that is where unfiltered queries most often appear. Only after each level behaves as expected should you add the next variable, so a fault can be traced to one query.
Repeating panels per host or service: design decisions
A repeating panel is only as good as the variable behind it. The decisions below determine how many panels appear, how they are arranged, and whether the dashboard stays readable and fast when the fleet grows. Check each one against a realistic host or service count before the dashboard is shared.
Choose the multi-value variable
Repeating works from a variable that allows multiple values and include-all selection. Each selected value produces one panel, so the variable defines the unit you repeat by, such as host, cluster or service. Pick the level your operators investigate at, because a variable at the wrong level either hides detail or floods the page. Check that the variable is set to multi-value before you enable the repeat option.
Set the repeat direction
Panels repeat horizontally or vertically. Horizontal repeats fill a row and suit a few series per panel, while vertical repeats stack and suit comparisons that need a readable time axis. The direction also affects how the dashboard wraps on smaller screens. Test both layouts with the largest value count you expect, not the current one.
Control how many values the query returns
A query variable decides how many panels appear, so a query that returns every host in a large estate can create a very long dashboard. Filter the variable query by a label, environment or team, and sort the results. Ask the data source owner for the expected count and confirm the query returns quickly, since each repeated panel also issues its own queries.
Size panels and layout for the value count
Each repeated panel keeps the height and width set on the original, so a large value count can push the rest of the dashboard far down the page. Set a fixed height that keeps axes and legends readable, and put repeated panels in a row that sits below summary panels. Confirm the layout with a value count at the top of your range, and check how many panels a single browser tab renders comfortably.
Keep repeated panels readable at scale
Dozens of small charts with long legends become hard to scan, and the eye loses the comparison that justified the repeat. Limit each panel to one or two series, use consistent axis limits where values should be compared, and keep titles short with the variable value shown. Ask a sample operator to find an outlier in the full set before you accept the design.
Handle an empty variable result
When a variable returns no values, the repeated row can disappear, leaving a dashboard that looks healthy when the data source is actually failing or the filter is wrong. Decide what the operator should see in that case, such as a text panel that explains the empty result. Test the dashboard with a filter that matches nothing, and confirm that the no-data state is distinct from a healthy fleet.
Building a reusable dashboard with variables, step by step
This sequence turns a one-off dashboard into a reusable template where one set of panels serves many hosts or services, and each step ends with a check you can run in your own instance.
Confirm the data source and label values
Start by checking that the data source returns the label values you plan to filter on. Open the data source's explore view in your Grafana instance and run a query that lists the values of the label, such as the host, service or environment label your metrics or logs carry. Note whether the values are consistent (for example, one naming pattern for hosts) and whether any series lack the label. The step is done when you can list the expected values from the data source directly and you know which label will drive the variable.
Create the top-level variable
In the dashboard settings, add the first variable and choose its type. For a list that comes from the data source, use the Query type and enter a query that returns distinct label values, such as the host or service label. Give the variable a short name, because the name appears in every query and in the URL. Save the dashboard and confirm the dropdown lists the same values you saw in explore. The step is done when the variable preview matches the source values.
Add chained variables
Add a second variable that depends on the first, such as an application or service filter scoped to the selected host. Reference the first variable inside the second variable's query so the list narrows as the first selection changes. Keep chains short, because each added level adds a query per refresh. The step is done when changing the top-level value updates the dependent list, and the dependent variable shows only values that exist under the selected parent.
Enable multi-value and include all options
For variables that should select more than one value, turn on multi-value. Turn on include All only where a view across every value is useful, and make sure the All option expands to a valid filter in your query, usually a regular expression match. Decide whether to set skipUrlSync on variables that carry sensitive or internal identifiers so they stay out of shared links. The step is done when selecting several values and All each produce the expected series, and the URL behaves the way your sharing policy requires.
Add a repeating panel
Create the panel you want to repeat, then set its repeat option to the multi-value variable and choose a direction for the repeated panels. Repeating panels are generated from the variable's current selection, so a query variable controls how many panels appear. Check the panel title includes the variable so each copy is identifiable. The step is done when each selected value produces one panel with its own data and title.
Test with empty, single and many values
Test the dashboard in three states: with no values selected, with one value, and with many values including All. With no values, confirm the dashboard shows a clear empty state and does not error. With one value, confirm the panel layout and queries are correct. With many values, check load time and that the layout remains readable at your typical screen size. The step is done when all three states render without query errors in the panel inspector, and you have recorded any values that break the queries.
Confirm shared links and permissions
Copy the dashboard URL with a selected variable value and open it in a private browser session with a user who has only Viewer access. Confirm the variable values in the URL are the ones you intended to expose and that no sensitive value appears. Check that the user can see the data they are permitted to see through your data source permissions. The step is done when the link reveals only the intended values and the viewer's access matches your access model.
Keeping sensitive values out of shared Grafana URLs
Variable selections are carried in the dashboard URL. When someone picks a host, a service or a customer identifier from a variable dropdown, Grafana writes that value into the address bar, so copying the link shares the selection along with the dashboard. A link pasted into a ticket, a chat thread or a wiki page can therefore expose hostnames, internal service names or customer IDs to anyone who opens it, including people who should only see the dashboard structure. The setting that controls this is skipUrlSync on each variable. Setting it to true keeps that variable's value out of the URL. Constant variables have it set to true by default, so the risk sits mainly with query, custom, text box and other variable types you create yourself.
Before you share a dashboard or document a standard link for a team, review every variable and mark the ones that hold sensitive values. Open the dashboard settings, go to the variables list and check each one's value and its URL sync behavior. Then open the dashboard in a private browser window, select a value and copy the resulting link to see what it reveals. Repeat this check after any change to the variables, because a new variable added later can reintroduce the exposure. Confirm the exact behavior of skipUrlSync in the version your team runs against the Grafana variables documentation, since a hidden variable still resolves its value when the dashboard loads.
Keeping values out of URLs does not replace access control. Anyone who can open the dashboard can still select a value from the dropdown and see the data behind it, and the data source and folder permissions decide who can query what. Treat skipUrlSync as hygiene for links that leave your normal viewing audience, not as a way to hide data from users who already have access. If a variable must stay private, restrict it through the folder that holds the dashboard and the permissions on the data source, and confirm those controls with whoever owns your Grafana access model.
Security and operational considerations for variable-driven dashboards
Variables make one dashboard serve many hosts, services and teams, which also makes it easier to expose data or overload a source by accident. The cards below cover the checks to run before a variable-driven dashboard reaches shared use, and the operational habits that keep it safe after upgrades and edits.
Query variables reveal metadata
A query variable runs a query against a data source and lists every value it returns, such as hostnames, tenant names or service identifiers. Anyone who can open the dashboard can usually open the variable dropdown, so a broad query can show inventory the viewer was never meant to see. Check what the query returns under each viewer's permissions, and narrow the query with label filters or a scoped data source before the dashboard is shared.
Selections leak through shared URLs
Variable selections are written into the dashboard URL, so a copied link can carry hostnames, tenant IDs or other values that are sensitive in their own right. Set skipUrlSync to true on variables whose values should stay out of links, and test by copying a URL and opening it in a private session. Constant variables already have this set by default, so check that you have not turned it off.
Provisioned versus UI-edited dashboards
A dashboard edited in the UI can drift from the code that defines it, and the next provisioning run may overwrite or conflict with those edits. Decide which dashboards are owned by files in Git and which are owned by authors in the UI, and set the provisioning options to match. Variable definitions are the part most likely to be changed casually, so keep them under review in the same way as queries.
Load from repeated panels
A repeating panel creates one query per selected value, so a query variable that returns several hundred hosts can multiply the load on the data source every time the dashboard refreshes. Limit the number of values with filters, default to a small selection, and set a sensible refresh interval. Ask the data source owner for query limits before a dashboard is published to a wide audience.
Chained variable queries
Chained variables make each dropdown depend on the one above it, which is useful for drilling from region to cluster to service. Each link in the chain runs its own query whenever the parent changes, so a long chain can slow the dashboard and hide a value that a later level expects. Test the full chain with a restricted account and with an empty parent selection to confirm the dashboard behaves as expected.
Review after each upgrade
Grafana releases change how dashboards, variables and panels behave, and a dashboard that worked on one minor release can render differently on the next. Keep a short list of variable-driven dashboards with their owners, and re-check the variable queries, repeat options and URL behavior after each upgrade. Use a staging instance with the same data source permissions to test before production. Permission design, such as which folders and roles can see these dashboards, is the next step to settle in the access model.
Questions teams ask before building variable-driven dashboards
Can our own team build variable-driven Grafana dashboards without outside help?
Yes, a team with query language skills and access to a Grafana instance can build variables and repeating panels itself, and many do. The work is not the hard part. The hard part is agreeing on which variables matter, which data source labels map to hosts or services, and how panels should behave when a value is empty. Teams that already own their data sources and have one or two engineers who know the query language usually build a first set in-house. Outside help tends to pay off when the dashboard set is large, when several teams need the same structure, or when reviews are slow because no one owns the standard. Ask a partner to separate design work from build work in the quote so you can see which part your team keeps.
What actually drives the effort of a variable-driven dashboard project?
Effort rises with the number of data sources, the number of dashboards that share variables, and the number of review cycles needed before sign-off. Each data source has its own query language, label naming and failure behavior, so a query variable that works on one system may need a different shape on another. Dashboard count matters because a shared variable definition must stay consistent across every dashboard that uses it. Review cycles add time when stakeholders disagree about host naming, default selections or which panels should repeat. Ask any provider to itemize these three drivers in the written scope so each one has a visible line and a stated number of revisions.
Do template variables work with every data source we run?
Variables are a Grafana feature, but what a query variable can return depends on the data source plugin behind it. Some sources support label or value lookups that populate a dropdown directly, while others need a custom query that returns a list in a specific shape. Before you commit, test each source with a small query variable and confirm that it returns values, handles an empty result and refreshes on the schedule you need. Check the variable and data source documentation for each plugin, and treat any gap as a design input rather than a surprise during rollout.
How do chained variables fail, and how do we catch it early?
A chained variable depends on another variable, so when the parent changes, the child must re-query and reset its selection. The common failures are a child that keeps a stale value, a child that returns no results because the parent selection is empty, and a long cascade that slows the dashboard because every level re-runs its query. Test chains with the parent set to each realistic value and with the parent set to All. Keep chains short, limit the number of queries each level runs, and record the expected behavior in the dashboard description so reviewers can check it.
Why do repeating panels for each host or service slow a dashboard down?
A repeating panel renders one copy per value of a multi-select variable, so every extra host or service adds queries and drawing work to the page. Query variables control how many panels appear, which makes the panel count a function of your inventory. An illustrative case: a fleet of a few dozen hosts repeats a panel with several queries each, which multiplies load on the data source at every refresh. Set a sensible maximum selection, use a shorter refresh interval only where people need it, and check the data source load before publishing to a wide audience.
How do we keep sensitive values out of shared Grafana URLs?
Set skipUrlSync to true on any variable whose value should not appear in the address bar, because a shared link then carries no variable state. Constant variables have this set by default, which is useful for internal endpoints or account identifiers you do not want copied into bookmarks. Note that skipUrlSync controls the URL, not the data source. Credentials belong in data source configuration, and access to the dashboard still depends on folder and role permissions. Review your dashboards for any variable that holds a customer name, internal host or tenant identifier before you share a link outside the team.
Who should own variable definitions after the dashboards go live?
One named owner should control shared variable definitions, naming conventions and the list of approved data sources, because a change to a single variable can affect many dashboards. Dashboard authors can own panels and layout, but query variables should change through a reviewed process. Ask the team that operates Grafana to decide where dashboard definitions are kept, since provisioning from files or as-code tooling makes review and rollback easier than editing dashboards in the browser. The owner also needs a schedule for reviewing variables when a data source or label scheme changes.
What should we confirm before estimating a variable-driven dashboard project?
Confirm the Grafana version you run, because variable behavior and editor screens change between releases, and confirm the list of data sources each dashboard will query. Next, list the dashboards that share variables, the people who must approve them and the audience that will view them. Finally, confirm whether dashboards will be provisioned from code or edited in the UI, since that decides how changes are reviewed and recovered. With these facts in writing, a provider can scope a fixed set of deliverables and revisions instead of an open-ended review.
How DeployOpen scopes and delivers Grafana dashboard design
DeployOpen treats Grafana dashboard variables and repeating panels as part of a self-hosted design, not an afterthought. We agree what the dashboards must answer, which variables and data sources sit behind them, and how sensitive values stay out of shared links before any dashboard is built.
How we scope
- Engagements are fixed-scope, with dashboards, variables and repeating panels listed in writing before work starts.
- The written scope names the data sources, host or service inventories and users each variable must serve.
- We agree which variables stay hidden from URLs, which dashboards repeat per host or service, and who owns each one.
How we build
- We design chained variables in dependency order, so each query variable filters only on values the previous one supplies.
- We test repeating panels against representative and empty variable selections, so layouts hold when a query returns nothing.
- Sensitive constant and text values are reviewed for skipUrlSync settings before any dashboard link is shared.
How we hand over
- We document each variable's type, query, default value, refresh rule and the panels or rows it controls.
- Dashboard JSON is kept in version control, and provisioning files are supplied so the design can be reloaded on a new instance.
- Handover includes a walkthrough with the dashboard owners and a checklist for adding new hosts or services.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial scope.
- Retainer support can cover reviewing dashboard changes after Grafana upgrades that affect variables or panel repetition.
- Confirm with us during scoping which support hours, response expectations and review cycles the retainer would include.
