Question
Data source Save & test passes but Explore queries fail — what the health check validates
Neel River
0 reputation · 07 Sept 2025, 08:10 UTC
103.4K views1
Loading…
0 reputation · 07 Sept 2025, 08:10 UTC
Teams need to confirm that a Grafana data source integration works before promoting it to production, ideally without using production credentials. The built-in Save & test button runs a lightweight health check against the configured endpoint, but its depth varies by plugin.
A successful health check typically confirms reachability and that the supplied credentials are accepted. For many core and third-party plugins, however, the probe is only a version or ping request — it does not verify that the account can execute the actual queries your dashboards depend on. Missing query permissions, an incorrect default database, TLS mismatches, or clock skew often surface only when a real panel query runs.
Core data sources (Prometheus, Loki, PostgreSQL, etc.) each implement their own health check logic. Community plugins may implement none at all, making Save & test effectively a connectivity ping. Without knowing exactly what request the plugin issues, teams cannot rely on the green result as evidence of readiness.
For a given data source plugin, how can you determine exactly what the Save & test endpoint calls without inspecting backend logs? What minimal representative query should be run in Explore to confirm the test credential has the permissions your dashboards require? Is there a documented matrix of health check behavior across core and community plugins for a specific Grafana version?
31275 reputation · 07 Sept 2025, 14:53 UTC
Save & test invokes whatever single probe the plugin author implemented—typically a version or ping request that proves reachability, TLS correctness, and credential acceptance. It does not prove the account can execute your real queries. There is no official cross-plugin matrix of health check behavior; you confirm it per plugin and validate permissions separately with a representative Explore query.
For core data sources, the probe is deliberately minimal:
grafanaSELECT 1), which does not require read grants on your tables.Backend plugins built on the Grafana plugin SDK implement a CheckHealth handler; community plugins may implement none, in which case the result degrades to little more than config validation. Consequently, a green check can coexist with Explore failures caused by missing read grants, a wrong default database or schema, TLS/SNI mismatches on query paths, or clock skew that only breaks time-range queries.
CheckHealth implementation; for frontend-only data sources, look at the health check route declared in plugin.json and the code it calls. This shows the exact request issued on save.Mirror what your dashboards actually do, using the data source's configured credentials:
up.SELECT ... FROM your_target_table LIMIT 1 against the real schema.The definitive proof of the gap: revoke one permission (e.g., read on the target table) in a staging setup and confirm Save & test still passes while Explore fails.
Probe depth is version- and plugin-specific and can change on upgrade, so re-verify after each Grafana or plugin release. Also note that Explore queries run with the data source's configured credentials, not the Grafana user's, unless the plugin implements per-user authentication. One detail that would sharpen this answer: which plugin and Grafana version you're on—behavior differs enough that the exact probe can only be stated per combination.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.