Observability gaps are discovered during incidents, which is the worst time and the most expensive. This matrix finds them in advance by asking a simple question per service: if this broke right now, would we know, and could we tell why?
Ask whether you would know, and whether you could explain. Two different questions. Alerts answer the first; logs and traces answer the second. A service with alerts but no useful logs tells you it is broken and nothing more.
Check how recent incidents were detected. Pull your last ten incidents and record whether monitoring or a human reported them first. Customer-detected incidents point straight at the gaps worth closing.
Count alert noise as a coverage gap. A service generating forty alerts a week is as unmonitored as one generating none, because nobody reads them. Track actionability alongside existence.
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Y / partial / N per column. The alerting column should cover user-visible symptoms, with infrastructure as the baseline.
| Service | Tier | Metrics | Logs centralised | Traces | User-symptom alerts | Dashboard | Runbook | SLO | Gap priority |
|---|---|---|---|---|---|---|---|---|---|
| checkout-api | 1 | Y | Y | Y | Y | Y | Y | Y | None |
| fin-db-02 | 1 | Y | Y | N | Partial | Y | Y | N | High (no user-symptom alert) |
More free templates IT teams use alongside this one.
Most SLOs are picked because 99.9% sounds respectable, then never referenced again. An SLO is only useful if a specific number of bad minutes triggers a specific decision, so this worksheet makes you write the error budget policy before you pick the target.
A runbook is read by a tired person at 03:00 who did not write it and does not know this service. That single constraint rules out most of what people put in runbooks: architecture background, rationale, and anything written in prose when it could have been a command.
The question that wastes most time at the start of an incident is who owns this. A register answering that in one lookup (with the on-call route, the runbook, and the dashboard) is worth more than most tooling.
Per service: metrics, centralised logs, traces, alerts on user-visible symptoms, a dashboard, a runbook, and an SLO, plus the service tier so gaps can be prioritised by how much the service matters.
Infrastructure alerts fire on CPU, memory, or disk and frequently have no user impact. Symptom alerts fire on what a user would notice: errors, latency, failed transactions. Symptom alerts are what you page on.
Yes, and it is functionally the same as having none. An alert that fires weekly and is never acted on trains people to dismiss the channel, so the genuine alert gets dismissed with it. Track actionability as rigorously as coverage.
