Find the import traps before the dashboard ships.

22 rules over a real parse of the dashboard: 7 errors, 11 warnings and 4 notes. The errors are the ones that change what Grafana does — a template variable nothing declares, a ${DS_…} placeholder with no __inputs block, an AngularJS panel that renders nothing on Grafana 11–12, two panels sharing an id, a repeat over a variable that does not exist, a panel with no type, and a schemaVersion so old that the JSON and the render are different dashboards. The warnings are the portability and review problems: a missing uid, a database id left in a committed file, a datasource referenced by name, a deprecated graph or singlestat panel, an invisible zero-width panel, a default time range longer than a year, a sub-ten-second refresh. Every rule has its own subsection on this page, and the playground's rule chips link straight to it.

No. The parser and all the rules are JavaScript running in your tab — there is no server, no API call and no logging, so 0 bytes are uploaded. That matters more here than for most tools: a dashboard JSON is a map of your internal estate. Metric names, datasource uids, hostnames in legend formats, service names in variable queries, sometimes an internal URL in a panel link. It is exactly the file you should not paste into a random online formatter.

No, and it says so rather than implying otherwise. Grafana’s dashboard schema is large, versioned and still moving, so a partial schema check presented as a schema check would be worse than no check at all. What this does is a structural lint: it reads the shapes that break imports and reviews — variables, datasource references, panel types, ids, layout, time and refresh — and names the JSON path of each finding. It does not parse PromQL, does not know your plugins, and does not talk to a Grafana. The full list of what it deliberately stays silent about is in "What it deliberately does not flag" above.

Because the file was produced by "Export for sharing externally". That export replaces every datasource reference with a placeholder — ${DS_PROMETHEUS} — and adds an "__inputs" block describing what each placeholder needs. Only the Dashboards → Import dialog reads that block and prompts you to pick a real datasource. Provisioning the same file, POSTing it to the API, or committing it into a Git-synced folder skips the dialog entirely, so the placeholder survives into the saved dashboard and every panel fails to resolve it. Either import it through the dialog, or substitute the real { type, uid } before you provision it. This linter reports the placeholder as an error either way, because the file cannot be provisioned as it stands.

The uid is the identifier you choose. It is part of the dashboard URL, it is what provisioning and the API address, and it should live in version control alongside the JSON. The id is a row number in one Grafana instance’s database — it means nothing anywhere else. A file with a uid updates the same dashboard every time it is imported; a file without one creates a new copy on every import. A file with a stale id either fails the import or targets a dashboard that has nothing to do with yours, which is why an export should carry "id": null.

The core graph, singlestat and table-old panels are migrated automatically when the dashboard loads, so they keep working — but the JSON in your repository is not migrated, which means the file you review and the panel Grafana renders are two different things. Re-save the dashboard from Grafana 9 or newer to write the migration into the file. AngularJS panel PLUGINS are a different story: grafana-piechart-panel, grafana-worldmap-panel and the rest have no automatic migration, and Angular support was deprecated in Grafana 9 and removed across Grafana 11–12, so those panels render nothing and have to be replaced by hand.

The rule set is pinned to grafana-12 / schemaVersion 41, printed on this page and on every copied report so a report is never ambiguous about what checked it. Version-sensitive rules are phrased as ranges — "Grafana 9–12", "removed across Grafana 11–12" — rather than as one exact release, because your instance is somewhere near this point rather than exactly on it. If your dashboard's schemaVersion is higher than 41, you get an INFO note saying so and the schema-specific findings are marked advisory. An unknown schema is a limit of this linter, not a defect in your dashboard, so it is never reported as an error.

Because Grafana does not fail — it interpolates nothing and runs the query with the literal text still in it. A PromQL selector of {env="$env"} matches no series, so the panel is empty; a regex-matching selector can match far MORE series than you meant, so the panel is populated and wrong. Neither case produces a message anywhere in the interface. The one exception this linter makes is a reference inside a string that looks like a regular expression, where "$" is also an end-of-line anchor: there the finding drops to a warning, because the "$env" you wrote may genuinely have been an anchor followed by text.

Up to 5,000,000 characters, which covers a generated dashboard of several thousand panels; a 500-panel dashboard lints in a few milliseconds. Past that limit it refuses with a message rather than freezing your tab, because an input that big is a log or an archive rather than a dashboard. Findings are capped too, at 50 per rule and 400 in total, and the panel states the cap and the real count whenever one applies — a truncated list that did not say it was truncated would be the same kind of quiet wrongness this tool exists to catch.