Convert Grafana Dashboard JSON to YAML — Provisioning-Ready

Grafana dashboards are JSON when you export them from the UI, but Grafana's provisioning config files (datasources.yaml, dashboards.yaml, alert rules) are YAML. If you're moving dashboards-as-code — exporting, reviewing in Git, re-provisioning — you need the JSON-to-YAML flip. This guide covers the dashboard workflow and the quirks around Grafana's nested JSON structure.

Dashboard Export to YAML Provisioning

1. In Grafana UI: Dashboard settings → JSON Model → copy.
2. Paste into our converter. Click Convert.
3. Save the YAML as dashboards/your-dashboard.yaml in your provisioning repo.
4. Commit. Your next Grafana reload picks up the provisioned dashboard.

Grafana's provisioning loader accepts both JSON and YAML for dashboards. The conversion is for your reviewers' sanity, not Grafana's.

Why YAML Dashboards Beat JSON for Review

A typical Grafana dashboard JSON is 500-2000 lines. The structure is deeply nested: panels → targets → datasource → query. Brace-tracking in PR diffs is painful. YAML with 2-space indent makes the nesting visible at a glance.

YAML also allows comments. A reviewer can see:

# CPU panel — threshold set to 80% after INC-4421
panels:
  - title: CPU Usage
    fieldConfig:
      thresholds:
        steps:
          - color: red
            value: 80

JSON can't hold that context. Comments live in the commit message or a wiki, which rot faster than the code.

Sell Custom Apparel — We Handle Printing & Free Shipping

Datasources and Alerts — YAML Native

Datasource provisioning files are YAML by default:

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    url: http://prometheus:9090
    isDefault: true

If you're generating datasource configs from a deployment tool that emits JSON, convert to YAML for the provisioning/datasources/ directory. Same for Grafana 9+ unified alerting YAML.

See also our JSON to Kubernetes YAML guide — if you're running Grafana in K8s, the dashboards-as-ConfigMap pattern uses the same conversion.

Nested JSON — What to Watch For

Grafana dashboards nest deeply. Typical structure:

dashboard:
  panels:
    - targets:
        - expr: rate(http_requests_total[5m])
          datasource:
            type: prometheus
            uid: PROM_UID

The converter handles arbitrary nesting fine. Things to watch:

• Large query strings — PromQL or SQL queries can be long. YAML's | block scalar makes them readable, but our converter doesn't auto-promote \n in input to block scalars. Hand-edit if the query is multi-line.
• Datasource UIDs — strings that look like numbers or UUIDs. Converter quotes correctly.
• Panel IDs — integers. Preserved as numbers (unquoted).

grizzly and Other Grafana-as-Code Tools

For serious dashboards-as-code workflows, check grizzly (a kubectl-style CLI for Grafana). It uses Jsonnet or YAML as source. Our browser converter is for the ad-hoc "export a dashboard, convert, commit" flow — quick and manual.

Tanka and Jsonnet-based approaches give you programmatic dashboard generation (shared templates, per-env overrides). For teams shipping 50+ dashboards, that pays off. For a handful of dashboards, plain YAML via our converter is lighter.

Frequently Asked Questions

Can Grafana load a JSON dashboard file via provisioning?

Yes — Grafana's dashboard provisioner accepts both JSON and YAML. Converting to YAML is about reviewer experience, not Grafana compatibility.

Will converting a dashboard change how it renders?

No — YAML and JSON represent the same data. Grafana renders identically from both. Conversion is purely format.

How do I handle dashboards with embedded template variables?

Template variables ($var, ${var}) are strings in the JSON. Our converter preserves them as strings in the YAML. Grafana evaluates them at render time.

Should I switch our whole Grafana-as-code pipeline to YAML?

If reviews are painful in JSON, yes — the diff and comment wins are real. If everything is automated (generated by Jsonnet, loaded directly), JSON is fine. Decide by who reads the files.