mediumFoundationSymptom-first#grafana#dashboard#no-data#query#panels

Grafana dashboard panels show 'No data' — query returns empty results

Dashboard panels display 'No data' or an empty chart

Likely source:configurationdata-loss

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Dashboard panels display 'No data' or an empty chart
  • Query inspector shows 200 OK but empty result array
  • Panels work for some time ranges but not others
  • Query uses a namespace or label that was recently renamed

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Query inspector output

    In Grafana UI: Panel → Inspect → Query → view the request and response

  • Time range selected in the dashboard

    Check the dashboard top-right time picker — ensure it is not set to a future date or an excessively short window

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • Query uses namespace="production" but the namespace was renamed to ns="prod"
  • Panel works in another dashboard that uses a different label
  • Query inspector shows the exact PromQL being sent

Confirm before fixing

curl -s 'http://<PROM-SERVER>:9090/api/v1/query?query=up{namespace="<OLD-NS>"}' | jq '.data.result | length'
READ

Test the exact label value the dashboard uses

Expected: 0 results if the label was renamed

Fix

curl -s -X POST -H 'Authorization: Bearer <TOKEN>' -H 'Content-Type: application/json' http://<GRAFANA>/api/dashboards/uid/<DASH-UID> -d '{"dashboard":<UPDATED-JSON>}'
CHANGE

Update the dashboard JSON to use the correct label name

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
curl -s 'http://<PROM-SERVER>:9090/api/v1/query?query=<GRAFANA-QUERY>' | jq '.data.result | length'
READ

Run the query directly against the datasource

2
curl -s -H 'Authorization: Bearer <TOKEN>' http://<GRAFANA>/api/datasources/<DS-ID>/health | jq '.status'
READ

Verify datasource health and permissions

3
In Grafana UI: Panel → Inspect → Query → Query Inspector
READ

View the exact query and response to identify mismatches

Prevention

  • Use Grafana variables ($namespace, $job) in panel queries instead of hardcoded label values.
  • Add a datasource health check panel at the top of every dashboard.
  • Use dashboard JSON version control so label changes are tracked.
  • Alert on Grafana panel error rate if using Grafana's built-in alerting.

Related runbooks

Same stack, same failure family — worth a skim.

Grafana dashboard panel shows 'Datasource with UID ... not found' after migrationhigh

Dashboard panels display 'Datasource with UID <uid> not found'

GrafanaIntermediate3 causes
Open runbook
Prometheus targets down — scrape failures with connection refused or DNS errorscritical

up == 0 for one or more targets on the /targets page

PrometheusFoundationUSE3 causes
Open runbook
Logs land in Loki but Grafana panel shows nothing — label matcher mismatchmedium

Grafana Loki panel shows 'No logs found' but the Loki API returns data

LokiIntermediate3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.