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.
Own at team level, with a named escalation person. Teams own services; individuals leave. Record the owning team plus a named technical escalation so there is a person to call when the rota is not enough.
Link straight to the runbook and dashboard. During an incident nobody wants a second search. Put the direct links in the register so the path from alert to diagnosis is one hop.
Hunt for orphans deliberately. Services whose owning team was reorganised away still run and still break. Reconcile the register against what is actually deployed each quarter.
Here's a preview. Unlock the free download to get all 3 sections (2 more below).
| Service | Tier | Owning team | Technical escalation | On-call route | Runbook | Dashboard | Depends on | Last reviewed |
|---|---|---|---|---|---|---|---|---|
| checkout-api | 1 | Payments | R. Okafor | #payments-oncall / PagerDuty: payments | wiki/runbooks/checkout-api | grafana/d/checkout-overview | Identity provider, payment gateway | 2026-10-01 |
| fin-db-02 | 1 | Infrastructure | A. Mehta | #infra-oncall / PagerDuty: infra | wiki/runbooks/fin-db | grafana/d/db-overview | Storage, network | 2026-10-01 |
More free templates IT teams use alongside this one.
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.
Services reach production without on-call ownership, alerts, or runbooks because nothing blocks them. A readiness review is only useful if it is a gate with an owner who can say no, not a form filled in afterwards.
A rota is more than a list of names against dates. This template covers the parts that cause real pages to go unanswered: who the secondary is, what happens when nobody acknowledges, and what the outgoing engineer must hand over.
The owning team, a named technical escalation contact, the on-call route, direct links to the runbook and dashboard, the service tier, its dependencies, and the date the entry was last reviewed.
By teams, with a named individual as technical escalation. Individual ownership creates a single point of failure and goes stale the moment that person changes role, while team ownership survives staff movement.
Reorganisations. A team is merged or dissolved and its services keep running with nobody formally responsible. Reconciling the register against what is actually deployed each quarter is the only reliable way to catch them.
