🚨 Grafana Error Guide: 'No data' — Fix Empty Panels and Empty Query Results

Overview

“No data” is not an error in the strict sense — the query ran successfully and returned zero series. Grafana displays this whenever a panel’s query is valid but the datasource has nothing to return for the current time range, filters, and variables. Because it looks identical whether the metric is genuinely absent or your query is subtly wrong, it is one of the most common support tickets.

The literal message on the panel:

No data

Compared to a red error banner (query failed) or “Data source not found” (datasource missing), “No data” means the request succeeded and the result set was empty. The job is to figure out why the result is empty.

Symptoms

• Panels render an empty area with “No data” while the datasource is healthy.
• The same query returns rows when run directly in Prometheus/Loki/SQL.
• Data appears at some time ranges but not others.
• A panel breaks only after a variable is added or changed.

Common Root Causes

1. Time range has no samples

The dashboard time range is outside the window where the metric has data (e.g. “Last 5 minutes” for a job that scrapes every 15 minutes, or a range before the series existed).

2. Variable interpolated to an empty/wrong value

$namespace resolves to nothing (or a value with no series), so the filtered query legitimately returns zero results.

3. Metric or label name typo / renamed metric

A relabel rule or exporter upgrade renamed the metric, so the exact string in the panel no longer exists.

4. Wrong datasource selected on the panel

The panel points at a Prometheus instance that does not scrape this target.

5. Query returns instant vs. range mismatch

An instant query at a moment with no sample, or a rate() over a window shorter than two scrape intervals, yields nothing.

Diagnostic Workflow

Step 1: Widen the time range and check the raw query

Bump the range to “Last 6 hours”, then open panel → Inspect → Query to see the fully interpolated query (variables resolved). Copy it and run it directly:

# Interpolated query from the panel, run directly in Prometheus
sum by (namespace) (rate(http_requests_total{namespace="prod"}[5m]))

If it returns nothing in Prometheus too, the problem is the data/query, not Grafana.

Step 2: Confirm the metric and labels exist

curl -s "http://prometheus:9090/api/v1/label/__name__/values" | jq -r '.data[]' | grep http_requests
curl -s "http://prometheus:9090/api/v1/label/namespace/values" | jq '.data'

An empty label list means the filter value (namespace="prod") matches no series.

Step 3: Check variable interpolation

sudo journalctl -u grafana-server --no-pager | grep -iE "interpolat|variable|query" | tail -20

In the panel’s Query Inspector, verify $namespace expanded to a real value. An empty multi-value variable produces namespace=~"" which matches nothing.

Step 4: Validate rate windows and step

# Needs at least two scrape intervals in the window
rate(http_requests_total[1m])   # too short if scrape_interval=30s under load
rate(http_requests_total[5m])   # safer

Step 5: For Loki, confirm the stream selector matches

{app="checkout"} |= "error"

Run it in Explore; if empty, loosen the selector ({app=~"checkout.*"}) to confirm labels.

Example Root Cause Analysis

A latency dashboard shows “No data” on every panel after a Prometheus relabeling change. The Query Inspector shows the interpolated query:

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket{service="api"}[5m])))

Running it directly in Prometheus also returns empty. Listing metric names shows the exporter now emits http_server_request_duration_seconds_bucket — the metric was renamed during a library upgrade, so http_request_duration_seconds_bucket no longer exists.

Fix: update the panel queries to the new metric name (or add a recording rule that re-exposes the old name during migration). Data returns immediately. The root cause was a renamed metric, invisible because the query itself was still valid PromQL that simply matched nothing.

Prevention Best Practices

• Default dashboards to a time range comfortably larger than the scrape interval, and avoid ranges shorter than 2× scrape interval for rate(); see more Grafana guides.
• Add an “All” option handling and sensible defaults to variables so an empty selection does not silently blank panels.
• Pin metric names via recording rules so exporter renames do not break dashboards overnight.
• Use the Query Inspector routinely to confirm variable interpolation before blaming the datasource.
• Alert on absent(metric_name) for critical series so a disappeared metric pages you instead of quietly showing “No data”.

Quick Command Reference

# Does the metric exist at all?
curl -s "http://prometheus:9090/api/v1/label/__name__/values" | jq -r '.data[]' | grep <metric>

# Do the filter label values exist?
curl -s "http://prometheus:9090/api/v1/label/namespace/values" | jq '.data'

# Server-side interpolation/query log
sudo journalctl -u grafana-server | grep -iE "interpolat|variable" | tail -20
kubectl logs deploy/grafana -n monitoring | grep -i query | tail -20

# Run the interpolated query directly (from Query Inspector)
# PromQL:  sum by (namespace) (rate(http_requests_total{namespace="prod"}[5m]))
# LogQL:   {app="checkout"} |= "error"

Conclusion

“No data” means the query succeeded and returned nothing — so debug the emptiness, not the datasource:

1. Widen the time range and copy the fully interpolated query from the Query Inspector.
2. Run that exact query directly in Prometheus/Loki; if it is empty there, the data is the issue.
3. Confirm the metric name and filter label values still exist.
4. Verify variables interpolated to real values and rate windows span at least two scrapes.

Nine times out of ten the culprit is a time range, an empty variable, or a renamed metric — all visible in seconds through the Query Inspector.