Dashboard import breaks data source references
A platform team maintains 40 dashboards in a staging Grafana 11 instance and needs to promote them to production. Both environments use Prometheus and Loki, but each data source was created manually, so UIDs differ, for example prom-stg-7f2 versus prom-prod-91c. An engineer exports one dashboard with the normal dashboard JSON export and imports it into production. Every panel shows "Datasource prom-stg-7f2 was not found"; one panel also shows "No data" because its panel-level data source override still points at staging. The dashboard has a datasource template variable, and several panels use $datasource. The admin wants a repeatable, low-risk process for all 40 dashboards and does not want engineers editing JSON by hand in production.
1. Why did the normal export fail after import, and what is the difference between that export and an export for sharing externally?
Read the worked answer
A normal dashboard export preserves the concrete data source UIDs used by the source instance. On import, Grafana has no reason to rewrite those UIDs, so panels keep referring to prom-stg-7f2, which does not exist in production. The panel-level override is a separate reference, so fixing the dashboard-level data source would still leave that panel broken. The $datasource variable also stores a current value, which may be a staging UID even if panels reference the variable.
An export for sharing externally adds input placeholders such as DS_PROMETHEUS and marks them for mapping during import. Grafana then prompts the importer to choose a production data source for each placeholder. That is the key difference: the external export replaces environment-specific UIDs with named inputs, while the normal export keeps them embedded.
2. Design a repeatable process for promoting all 40 dashboards without hand-editing JSON.
Read the worked answer
Provision production data sources with stable UIDs that match staging, or at least use a small, documented UID convention. If the UIDs match, normal dashboard JSON becomes portable and the remaining issue is the datasource variable's current value. For the dashboards themselves, keep the JSON in version control and deploy through provisioning or the dashboard API. Use an external-style export with __inputs placeholders for Prometheus and Loki, and automate the import mapping with the same placeholder names across all 40 dashboards.
For the templated data source variable, either replace it with a fixed data source reference where the dashboard does not need switching, or ensure the provisioning process sets its current value to the production UID. Validate with a smoke test that checks each panel returns data in production, not just that the dashboard imports without an error.
3. What specific checks would you run on the first imported dashboard before promoting the other 39?
Read the worked answer
Check the dashboard JSON for any remaining staging UIDs, including panel-level overrides and the datasource variable's current value. Open the dashboard and inspect every panel for the datasource error, not just the first one. Use the query inspector on a representative Prometheus panel and a Loki panel to confirm the expanded query and returned frames. Test the $datasource variable by switching it if the dashboard supports multiple sources, and confirm panels follow the selection.
Then check that variables, links, and annotations do not reference staging-only objects. Run a diff between staging and production panel results for a fixed time range where possible. Only after the first dashboard passes these checks should the same automated mapping be applied to the remaining 39, with a post-import check that fails the pipeline if any panel has an unresolved data source UID.