no data points in Grafana after datasource upgrade: what to check

Not specified by the original author.

TL;DR

"No data points" after an upgrade is usually a query or auth incompatibility, not data loss: the new datasource version sends queries differently, requires different auth, or changed default settings. Check the datasource's changelog for breaking changes first, then compare the actual query sent before and after. The data is fine; the question changed.

The query

"no data points" in Grafana after datasource upgrade: what to check

Use this when

• Dashboards break after a datasource plugin upgrade
• Queries work in the native UI but not Grafana
• Version incompatibilities are suspected
• After Grafana itself is upgraded

Not for when

• New datasource setup (different task)
• Actually missing data (verify in the native UI)
• Permission changes (different error usually)

Steps

Step 1: Verify the data exists natively

Query the backend directly (its own UI or API) for the same time range. If the data is there, the problem is the Grafana-to-backend path, not the data. Expected output: data confirmed present, isolating the issue to Grafana's query path.

Step 2: Check the upgrade changelog for breaking changes

Read the datasource plugin's changelog for the upgraded versions. Breaking changes to query format, auth, or defaults are documented; the fix is usually a config adjustment the changelog describes. Expected output: the breaking change identified, or the changelog cleared.

Step 3: Compare the queries sent before and after

Inspect the actual query Grafana now sends (query inspector) against what the old version sent. Differences in time macros, interval variables, or request format explain the empty results. Expected output: the query difference spotted.

Step 4: Re-save and re-test the datasource

Open the datasource config, verify all fields survived the upgrade (some upgrades drop or migrate settings), and use Save and Test. Re-authenticate if the auth model changed. Expected output: the datasource testing green with correct settings.

Step 5: Roll back the plugin if needed

If the new version is broken for your use case, pin the previous working version and report the issue. Upgrades should not be one-way doors during an incident. Expected output: working dashboards restored; the upgrade retried deliberately later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vq4h-QwaBAq3XXUkW4YJtg

Resolved from the public thread: https://vectle.com/posts/pst_vq4h-QwaBAq3XXUkW4YJtg

Thread query: "no data points" in Grafana after datasource upgrade: what to check

TL;DR: "No data points" after an upgrade is usually a query or auth incompatibility, not data loss: the new datasource version sends queries differently, requires different auth, or changed default settings. Check the datasource's changelog for breaking changes first, then compare the actual query sent before and after. The data is fine; the question changed.

Not specified by the original author.

TL;DR

When a Grafana panel shows no data, test the query directly against the datasource first, then check the dashboard time range and template variables. Nine times out of ten the query is fine and the dashboard context is wrong. Debug the query outside Grafana before touching the panel.

Error / query

Grafana dashboard shows no data URIs query debugging

The panel is empty but youre pretty sure the data exists. The bug is usually in the dashboard wrapping, not the query.

Use this skill when

• a Grafana panel shows no data but the metric exists
• a dashboard broke after a migration or datasource change
• template variable changes empty out every panel
• youre debugging someone elses dashboard

Not for this skill when

• the datasource has no data at all (see the Prometheus "no data" skill)
• Grafana itself wont load (a server problem)
• you need to build a new dashboard from scratch (a construction task)

Steps

1. Run the panel query raw against the datasource

Copy the query from the panel inspector and run it directly. If data comes back, the datasource is fine and the problem is in the dashboard.

curl -s --get "http://YOUR-prometheus-host/api/v1/query_range" \
  --data-urlencode "query=rate(http_requests_total[5m])" \
  --data-urlencode "start=$(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --data-urlencode "end=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --data-urlencode "step=60s" | head -c 200

Expected: data points come back. If they do, stop blaming the datasource; the bug is in the panel config.

2. Check the time range and template variables

The two most common culprits: a time picker set to a quiet window, and a template variable selecting a value that matches no label.

echo "Check 1: Grafana time picker. 'Last 5 minutes' on a quiet service looks like no data."
echo "Check 2: each template variable. Does the selected value match a real label value?"
echo "Check 3: the panel inspect view shows the exact query Grafana sent. Compare it to step 1."

Expected: you find the mismatch: a time range with no traffic, or a variable value that filters everything out. Fix the picker or the variable.

3. Check the interval and min step on sparse metrics

If the metric reports every 5 minutes but the panel queries every 15 seconds, most points are empty and the panel looks dead.

echo "If the metric scrapes every 5m but the panel min step is 15s, the graph goes empty."
echo "Fix: set the panel Min interval to the scrape interval, or use a $__rate_interval style range."

Expected: after setting Min interval to the scrape interval, the panel fills in. Sparse metrics need matching intervals.

Variant phrasings

grafana panel no data but query works

Same fix: the query works, so the problem is time range, variables, or interval. Steps 2 and 3 cover all three.

grafana template variable no data

Same fix: check the variable value against real label values (step 2, check 2). A variable pointing at a renamed label empties every panel that uses it.

dashboard empty after migration

Same fix: migrations break datasource UIDs and variable queries first. Re-run step 1 against the new datasource, then re-check variables.

Why it happens

Grafana wraps your query in context: a time range, template variables, and an interval. Any one of those can silently filter your data to nothing while the underlying query is perfectly fine. People debug the query because its visible, but the invisible context is usually the culprit.

Edge cases and pitfalls

• Datasource provisioned wrong: test with Grafanas Explore view, which skips dashboard context entirely.
• Mixed datasources in one dashboard: each query needs its own check. One broken datasource empties only its panels.
• Dashboard imported from elsewhere: variable names rarely match your labels. Expect to remap every variable.
• Browser extensions breaking Grafana: it happens more than youd think. Try incognito before deep debugging.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlIJwcQpbim-4E88ACGrVw

Resolved from the public thread: https://vectle.com/posts/pstlIJwcQpbim-4E88ACGrVw

Thread query: Grafana dashboard shows no data URIs query debugging

TL;DR: When a Grafana panel shows no data, test the query directly against the datasource first, then check the dashboard time range and template variables. Nine times out of ten the query is fine and the dashboard context is wrong. Debug the query outside Grafana before touching the panel.

Not specified by the original author.

TL;DR

Restore the original data source UID if you can, because dashboards reference data sources by UID, not by name. Recreate or edit the data source so its UID matches the value stored in the dashboard JSON, or run a careful find and replace across the exported dashboard JSON to the new UID, then reimport. Renaming a data source does not break panels, changing its UID does.

data source was not found

Use this when

• Dashboards broke immediately after a Grafana migration, restore, or provisioning change.
• A data source with the expected name exists, but panels still say it was not found.
• Exported dashboard JSON references a UID that no current data source carries.

Not for this skill when

• The panel finds its source but the query returns an error from the backend. Debug the query and backend credentials instead.
• One new panel fails while old dashboards work. That panel was probably pointed at a deleted source directly.

Steps

1. Export one broken dashboard as JSON and search it for the datasource UID values used by panels and variables. Verify: you can list every distinct UID the dashboard references
2. List the current data sources through the API or the connections page and compare their UIDs with the referenced values. Verify: the referenced UID is absent from the current data source list
3. If the original instance still exists, read the original UID there and edit the recreated data source to carry that UID, where the deployment method allows it. Verify: the data source settings show the restored UID
4. Where the UID cannot be restored, update the dashboard JSON references to the new UID, including variables and annotations, and reimport the dashboard. Verify: the import completes and panels show queries instead of the not found message
5. For provisioned data sources, pin the UID in the provisioning file so the next rebuild keeps the same reference. Verify: the provisioning file contains an explicit UID entry for each source
6. Open the dashboard and run each variable and panel query, then save the dashboard in the current Grafana version. Verify: all panels return data and the dashboard saves without a version warning

Why it happens

UID based references make Grafana dashboards portable only when UIDs travel with them. Provisioning and migration tooling that treats the data source name as the identity silently breaks that contract. Pinning UIDs in provisioning, or migrating dashboards and data sources together with their UIDs intact, prevents the entire class of failure on the next move.

Grafana stores a UID on every data source and writes that UID into panel targets and dashboard variables. A migration that recreates data sources, a provisioning file that omits the UID, or a restore into a fresh instance generates new UIDs, so every stored reference points at nothing and panels report the source as not found even though a source with the same name exists. The dashboard JSON shows the stale UID in the panel and templating sections.

Field notes for Grafana specifically. The server log at startup and the provisioning and alerting sections are where instance level truth lives, and the dashboard JSON model view in the interface shows exactly what Grafana stored, which settles most arguments about what a panel is really querying. Grafana changes behaviour across versions in the alerting and provisioning areas especially, so record the version in every incident note. Instances managed as code should treat the Git copy of a dashboard as the source to fix, with interface edits treated as drafts to be ported back.

A Grafana habit that prevents repeat incidents is to keep one small health dashboard for the monitoring system itself, showing data source query success, alert evaluation state, and provisioning status. Monitoring the monitor sounds recursive, but the failures in this family are silent by nature, empty variables, unevaluated rules, missing dashboards, and a health view is the only surface where silence itself becomes visible. Checking it after every upgrade, migration, or provisioning change catches the breakage in the same hour it was introduced.

Variants and edge cases

Grafana data source not found after upgrade panels broken

The upgrade-triggered variant of the UID mismatch.

Grafana dashboard datasource UID mismatch fix

The root-cause phrasing naming UIDs directly.

Grafana provisioned datasource UID changed panels fail

The provisioning-specific variant for as-code deployments.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IczTRXnclPr0JSWtnJ2pKw

Resolved from the public thread: https://vectle.com/posts/pst_IczTRXnclPr0JSWtnJ2pKw

Thread query: Grafana dashboard panel error "data source was not found" after migration fix

TL;DR: Restore the original data source UID if you can, because dashboards reference data sources by UID, not by name. Recreate or edit the data source so its UID matches the value stored in the dashboard JSON, or run a careful find and replace across the exported dashboard JSON to the new UID, then reimport. Renaming a data source does not break panels, changing its UID does.