# Data source badge > The viewer needs to know where a panel's data comes from and whether that source is healthy. - Canonical: https://patterns.konigi.com/dashboards/data-source-badge - Group: Meta information - Level: implementation - Status: published - Updated: September 10, 2026 - Also called: provenance, connector health --- ## Problem Two panels on the same dashboard disagree about the same number. One reads from the warehouse, one from the production replica, and nothing on the page says so, so the argument that follows is about which team is wrong rather than about which source is which. ## Solution Say where the number came from, on the panel, without being asked. A small label naming the source, its health, and ideally the query behind it. The pattern is unglamorous and its value shows up only in specific moments, which is why it gets cut. Those moments are expensive: an incident where a source is lagging, a review where two numbers disagree, and the first week of anyone new who has no idea the company has three places a "user count" can come from. Grafana's model makes the need obvious. Data sources are configured objects, panels reference them by name, and a single dashboard can mix Prometheus, Loki, a SQL database and a spreadsheet in adjacent panels. Nothing about the rendered result reveals that, and the panels look equally authoritative. There are three separable things a badge can carry, and they are worth distinguishing rather than bundling. **Identity.** Which configured source this is. Cheapest, most useful, almost always sufficient. **Health.** Whether that source is currently reachable and current. This overlaps with freshness and error states, and the badge is the right home for it when the panel is otherwise fine—a healthy-looking chart from a source that is twenty minutes behind is the case nothing else catches. **Derivation.** What was actually asked. A link to the query, or the query itself in a popover. This is the one that ends disputes, and the one most products treat as an advanced feature. ## Use when A page mixes sources, or the same metric exists in more than one system, or the audience will act on the number without knowing the plumbing. Any executive-facing dashboard qualifies on the last point alone. ## Don't use when Every panel on the page reads from one source and everyone knows it. Then the badge is repeated noise, and saying it once at page level is enough. ## Trade-offs Badges take space from the panel and get read only occasionally, which makes them permanently vulnerable at design review. Source names are internal and often meaningless to the audience—`prom-prod-2` tells an executive nothing and might tell an engineer the wrong thing. Health indicators need their own monitoring, and a badge that shows healthy because its check is also broken is worse than no badge. And exposing the query invites people to reason about SQL they may misread, which is a real cost weighed against the disputes it settles. ## Checklist - Does the panel say which source it read from? - Is the source name meaningful to this audience, or only to the person who configured it? - Does the badge carry health as well as identity? - If the source is lagging but responding, does anything on the page say so? - Can a viewer reach the query behind the number? - Do two panels showing the same metric from different sources make that visible? - Is the badge redundant on a single-source page, and could it be stated once? - Does the health check have its own failure mode, and what does the badge show then? - Is the badge reachable by screen reader, or is it an icon with a tooltip? - When a source is renamed or replaced, what updates the badges? ## Compare **Grafana** treats data sources as first-class configured objects that panels reference by name, which makes mixed-source dashboards easy to build and makes provenance entirely a matter of whether the author chose to surface it. **Datadog** mostly removes the question by owning ingestion, so the interesting provenance is the tag scope rather than the connector, and its UI reflects that. **Honeycomb** collapses source and query into one thing—you are always looking at a dataset you named in the query—so provenance is never ambiguous and never needs a badge. **Looker** pushes hardest in the other direction with a modelling layer, so a metric has one definition and the badge question becomes "which model version", which is a better question and a harder one to answer in a corner of a panel. ## Related Freshness indicator answers when, where this answers where from, and the two are usually needed together. Error and stale state is what the panel shows once the source stops answering. Explain this metric covers the definition question that provenance raises. Empty state is where an unreachable source often surfaces first. Alert rule is what should notice a source going quiet before a viewer does. ## Examples ### Honeycomb Query-first; heatmaps and BubbleUp replace the dashboard-of-panels model with draw-a-region cross-filtering. **Query / HEATMAP(duration_ms)** — captured September 10, 2026, Honeycomb sandbox, public dataset (signed out; no version string exposed). analytical, medium density, light theme, desktop-web. My heatmap entry cites Honeycomb as the argument for log-scale y-buckets, so it's worth recording that this is Honeycomb's own sandbox rendering the same chart on a linear axis. The result is the failure the argument warns about: the ticks run 0 to 3500 evenly, the dense band where almost every request actually lives is squashed into the bottom sixth of the panel, and the top half is mostly empty. What survives anyway is the thing a percentile can't tell you. The solid band under a second doesn't move across the whole window, while from about 07:00 a separate purple tail climbs to 3000ms and keeps going. Two populations, one of them fine and one of them deteriorating. A p95 line over this data would have risen and said nothing about which. The other thing worth stealing: the footer reports elapsed query time and that it examined 11,710,335 rows, so the panel tells you what it cost and how much it looked at. Cookie banner and a no-signup onboarding modal were removed to take the shot; nothing of the product's own UI was. Hotspots in this capture: - [Heatmap](https://patterns.konigi.com/dashboards/heatmap) — Linear y-axis, so the band holding most requests is six percent of the panel height and the empty top half gets the rest. - [Dashboard builder](https://patterns.konigi.com/dashboards/dashboard-builder) — No panel to configure—the query is the page. WHERE trace.parent_id does-not-exist is how you say root spans only. - [Tabs as genres](https://patterns.konigi.com/dashboards/tabs-as-genres) — Five readings of one result: overview, BubbleUp, correlations, traces, raw. Each tab is a different question, not a different subject. - [Search across panels](https://patterns.konigi.com/dashboards/search-across-panels) — The schema is the navigation, and it opens with a filter box rather than a tree you're expected to browse. - [Time-range picker](https://patterns.konigi.com/dashboards/time-range-picker) — Absolute, with the granularity stated beside it, and arrows that step to the previous window rather than retyping it. - [Data source badge](https://patterns.konigi.com/dashboards/data-source-badge) *(this pattern)* — Elapsed query time and 11,710,335 rows examined. The panel reporting its own cost and scope, which almost nothing else does. - [Freshness indicator](https://patterns.konigi.com/dashboards/freshness-indicator) — When data last arrived, not when the page last ran. The one of the three ages that actually matters. ### Grafana (Grafana Labs) The reference implementation for panel grids, template variables, and stat panels; most other tools are defined by how they differ from it. **Linux node / fleet overview** — captured September 9, 2026, Grafana Play (signed out; no version string exposed). operational, medium density, dark theme, desktop-web. Captured while Play's demo data source was returning nothing, which makes this a better example of empty and error states than of the fleet overview it is meant to be. Three things are worth noticing. The top-left tile is red and reads "No metrics received - Check configuration", which is an actual diagnosis and the best thing on the page. The tile beside it exists to report when data last arrived, and it says "No data", so the freshness indicator has no freshness to report and doesn't say why. And every chart below says "No data" while the network panel says "No errors". A viewer scanning this page cannot tell from the words alone whether the network is clean or whether it is as unknown as everything else, which is the exact confusion the empty-state pattern exists to prevent. Hotspots in this capture: - [Header KPI strip](https://patterns.konigi.com/dashboards/header-kpi-strip) — Three status tiles across the top, before any chart. - [Error and stale state](https://patterns.konigi.com/dashboards/error-and-stale-state) — Red, and it names the cause: no metrics received, check configuration. - [Freshness indicator](https://patterns.konigi.com/dashboards/freshness-indicator) — The tile whose job is 'as of when', reporting No data instead. - [Data source badge](https://patterns.konigi.com/dashboards/data-source-badge) *(this pattern)* — Integration version, the only tile on the row still able to answer. - [Empty state](https://patterns.konigi.com/dashboards/empty-state) — No data, centred, with no distinction from a genuine zero. ## Related patterns - [Freshness indicator](https://patterns.konigi.com/dashboards/freshness-indicator) — The viewer is about to act on a number and doesn't know how old it is. - [Error and stale state](https://patterns.konigi.com/dashboards/error-and-stale-state) — One panel's query failed and the viewer must not mistake it for a zero. - [Explain this metric](https://patterns.konigi.com/dashboards/explain-this-metric) — Two people read the same tile and mean different things by it. - [Empty state](https://patterns.konigi.com/dashboards/empty-state) — There's nothing to show, and the page has to say why and what to do. - [Alert rule attached to panel](https://patterns.konigi.com/dashboards/alert-rule) — The chart shows the line to watch; the viewer wants to be told when it's crossed. ## Sources - [Grafana, Data sources](https://grafana.com/docs/grafana/latest/datasources/) - [Nielsen Norman Group, Visibility of System Status](https://www.nngroup.com/articles/visibility-system-status/) - [Bach et al., Dashboard Design Patterns](https://dashboarddesignpatterns.github.io/patterns.html) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.