Grafana Dashboard Panels Not Loading or Showing No Data Fix

You open Grafana and half the panels show "No data" while others spin indefinitely. This is one of the most frustrating debugging experiences in a monitoring stack. Here is a systematic guide to find and fix every common cause.

Step 1: Test the Datasource Connection

The first thing to check is whether Grafana can actually reach your datasource.

Go to Configuration → Data Sources → your datasource → Save & Test. If it fails, you have a network or auth issue, not a panel issue.

For Kubernetes-hosted Grafana, check if the Prometheus service is reachable from the Grafana pod:

kubectl exec -n monitoring deploy/grafana -- wget -qO- http://prometheus-operated:9090/-/healthy

If that hangs or returns an error, fix the service endpoint in your datasource config. The Prometheus URL inside Kubernetes should be the in-cluster service DNS — something like http://prometheus-operated.monitoring.svc.cluster.local:9090, not localhost.

Step 2: Check Grafana Logs

kubectl logs -n monitoring deploy/grafana --tail=100 | grep -i "error\|datasource\|plugin"

Common log messages and what they mean:

• dial tcp: connection refused — Prometheus is down or wrong port
• context deadline exceeded — query takes too long, Prometheus is overloaded
• plugin not found — you are using a panel type whose plugin is not installed
• datasource not found — a provisioned dashboard references a datasource UID that does not exist

Step 3: Fix Time Range Issues

A very common cause of "No data" is the dashboard time range not matching when your data was ingested.

• Default dashboard range is Last 6 hours. If you just deployed Prometheus, there may only be 10 minutes of data.
• Some panels have a relative time override set at the panel level that overrides the dashboard range. Check: Panel edit → Query → Relative time.
• If your system clock is off on the Prometheus node, metrics timestamps will be wrong. Run date on the node and compare.

For panels showing "No data" on exactly the last N minutes, check if Prometheus scrape interval is longer than your panel refresh rate:

# prometheus.yml
global:
  scrape_interval: 60s   # if this is 60s but panel queries last 30s, you will see gaps

Change scrape interval or widen the panel's minimum step / resolution.

Step 4: Debug Variable Not Resolving

If your dashboard uses template variables like $namespace or $cluster and panels show "No data", the variable may not be resolving.

Go to Dashboard Settings → Variables. Click the variable and check:

• Query: does the datasource return values? Click Preview of values.
• Refresh: set to "On Dashboard Load" or "On Time Range Change".
• Regex: an overly strict regex can filter out all options.

Check your panel query: if it contains namespace=~"$namespace" and the variable value is All, Grafana sends namespace=~".*" — this is fine. But if the variable is empty (""), the query becomes namespace=~"" which matches nothing.

Fix: set a default value for the variable, or use $__all_value correctly.

Step 5: Fix Prometheus Scrape Interval vs Panel Interval Mismatch

When you use rate() or irate() in Prometheus queries, the range must be at least 2x the scrape interval.

# BAD: scrape_interval=60s but range is 1m — may return no data or wrong results
rate(http_requests_total[1m])
 
# GOOD: use at least 2x scrape interval
rate(http_requests_total[2m])

Better: use $__rate_interval which Grafana calculates automatically:

rate(http_requests_total[$__rate_interval])

Step 6: Mixed Datasource Issues

If a panel uses "Mixed" as its datasource, each query must have its datasource explicitly set. If any query has its datasource left as default and the default is not set or is wrong, that query returns no data.

Panel edit → each query row → check the datasource dropdown on the left of the query.

Step 7: Plugin Not Installed

If a panel shows a blank grey box with no error message, the panel plugin (like a pie chart plugin, worldmap plugin, etc.) may not be installed.

# List installed plugins
kubectl exec -n monitoring deploy/grafana -- grafana-cli plugins ls
 
# Install a missing plugin (requires restart)
kubectl exec -n monitoring deploy/grafana -- grafana-cli plugins install grafana-piechart-panel
kubectl rollout restart deploy/grafana -n monitoring

For Helm-managed Grafana, add the plugin to values.yaml:

grafana:
  plugins:
    - grafana-piechart-panel
    - grafana-worldmap-panel

Step 8: Fix Provisioned Dashboard YAML Errors

If you provision dashboards via ConfigMaps or Helm, a broken JSON inside the YAML causes the whole dashboard to fail silently.

# Check provisioning logs
kubectl logs -n monitoring deploy/grafana | grep -i "provision\|failed to load"

Common issue: the dashboard JSON was exported with a uid field but the datasource UID in the JSON does not match any datasource configured in Grafana. Fix by using ${DS_PROMETHEUS} as a variable in the datasource field instead of a hardcoded UID, and defining the __inputs block in the dashboard JSON.

Step 9: Fix Broken Panel JSON

If one specific panel is broken after editing, go to Panel edit → three-dot menu → Edit JSON. Look for:

• "datasource": null — replace with your datasource name or UID
• "targets": [] — empty query array, add a query
• Missing "type" field on the panel object

You can also remove the broken panel and re-add it from scratch — Grafana panels are just JSON, so exporting a working panel from another dashboard and pasting the JSON is faster than debugging.

Quick Diagnostic Checklist

Start with the datasource test and Grafana logs — they catch 80% of cases in under five minutes.

For affiliate resources: Grafana Cloud free tier for managed monitoring, Prometheus Operator via kube-prometheus-stack Helm chart for full stack setup.