How to Build a Service Health Summary That Handles Missing Data
Sources and verification
- Source dates
- Oldest source check: 12 September 2026.
- Technical verification
- Separate technical verification has not been recorded.
Publication approval and technical verification are recorded separately. Automated link checks establish reachability, not accuracy. A checked example verifies only its stated test cases, not the whole article or your production setup.
In short
Build the summary from an authoritative service inventory and an explicit health policy, then join current observations onto that inventory. Count each service once and preserve unknown, stale and maintenance states. Distinguish expected silence from failed collection using schedules and source health. A dashboard count or empty query result cannot establish how many services are healthy.
Key takeaways
- Use service inventory as the denominator instead of the number of dashboards.
- Unknown and stale observations must not inflate the healthy total.
- Expected silence needs an explicit schedule and independent collection evidence.
Count services from inventory
A service may appear on several dashboards, and one dashboard may represent many services. Counting panels or dashboards therefore answers a presentation question rather than an operational one.
Start with a maintained service list containing stable identifier, environment, owner and required health signals. Join observations onto that list so an expected service with no measurements remains visible. Decide whether the summary includes retired services, internal tools and maintenance windows before calculating totals.
An illustrative inventory of twenty services should still account for twenty service states when one collector fails. If the display suddenly contains only nineteen services, it has likely hidden a coverage gap.
Define one state policy per service class
| State | Meaning in the summary |
|---|---|
| Healthy | Required current observations meet the accepted policy |
| Degraded | A meaningful condition fails while some service remains available |
| Unavailable | The defined availability condition fails |
| Unknown | Evidence is absent, stale, incomplete or cannot be evaluated |
| Maintenance | An explicit active maintenance policy applies |
These are proposed summary states, not a claim that every monitoring system implements them identically. Document how conflicting signals are resolved. A failed customer transaction should not be overruled by a healthy process check.
Keep the source observations and their ages accessible from each state. The summary should explain why a service is classified, not just assign a color.
Distinguish expected silence from broken observation
A batch service may legitimately emit no business events overnight. That silence is expected only if its schedule and input contract say so. A failed database query or unreachable collector is a different condition, even when both produce an empty chart.
Track last successful collection independently from last business activity. A healthy collector observing zero requests can support “no traffic”; an unavailable collector supports only “traffic unknown.” Include maintenance schedules and timezone changes explicitly rather than deriving them from missing results.
Grafana's missing-data guide (opens in a new tab) and No Data and Error reference (opens in a new tab) describe distinct failure states that need intentional treatment. Do not map all of them to healthy merely to keep the overview quiet.
Aggregate without hiding coverage
Display healthy, degraded, unavailable, unknown and maintenance counts alongside the total in scope. Show the inventory revision or refresh time and the observation freshness boundary. If a source is incomplete, identify the affected group.
Avoid averaging status codes. Combining healthy and unavailable numerical values can create a meaningless middle state. Evaluate the service policy first, then count the resulting categories.
Also preserve criticality where it affects response. Nineteen healthy development services do not offset one unavailable production checkout service. Google's monitoring guidance (opens in a new tab) emphasizes user-facing symptoms as a useful basis for monitoring decisions.
Test inventory and observation failures
Use a controlled dataset with a healthy service, a degraded service, an expected idle batch job and a service whose source is unreachable. Confirm that the totals reconcile with inventory and the latter two remain distinguishable.
Then remove an observation, duplicate a dashboard entry, add a new service and expire a maintenance window. None should silently inflate the healthy count. Have another responder open an unknown service and identify the first check using its source and freshness information.
Keep the policy and fixture set with the summary's owner. Repeat them after changing a data source or aggregation rule, and label any service whose coverage has not yet passed the exercise.
Did this help?
Your answer helps us improve this guide. We save only the page and your choice for 30 days.
No name, email, or incident details are requested.
Sources
Vendor facts change. Each source below shows the date this page last checked it.
- Handle missing data — Grafana Labs. Checked 12 September 2026.
- No Data and Error states — Grafana Labs. Checked 12 September 2026.
- Monitoring distributed systems — Google SRE. Checked 12 September 2026.
Related
One practical idea, occasionally
The On-Call Brief: short field notes, templates, and operational lessons.
Follow the field guide
Email subscriptions are not open yet. Read new guides in your feed reader — no email address needed.
Subscribe with RSS