Runbook Ownership

Assign every runbook an owner and a team; review quarterly so runbooks don't rot.

Why

A runbook without an owner is an orphan — when the system changes (new deploy tool, renamed service, migrated DB), nobody updates the runbook, and the next incident finds a runbook that tells the on-call to run a command that no longer exists. This is runbook rot, and it's the most common reason runbooks fail during real incidents. An owner (a team, not a person — people leave) is responsible for keeping the runbook current when their system changes, and a quarterly review catches rot that slipped through. The review is cheap: for each runbook, run through the steps in staging; if a command fails or a link 404s, fix it. Teams that do this report 95% of runbooks work on first try during incidents; teams that don't report 40% — and the 60% that fail cost 15 minutes each of confused debugging.

When

When a runbook is written. Review all runbooks quarterly; review a runbook immediately when its system changes.

How

1. Assign every runbook an owner (team) and a primary author
   - Owner = the team that owns the system the runbook is for
   - Store in the runbook frontmatter: owner: @team-payments, author: @alice
   - The owner is responsible for keeping it current, not the author

2. Make runbook updates part of the system-change checklist
   - "Renaming a service? Update all runbooks that reference the old name."
   - "Migrating the DB? Update all DB runbooks with the new connection string."
   - Code review: if a change breaks a runbook, require the runbook update in the same PR

3. Run a quarterly runbook audit
   - For each runbook: walk through the steps in staging
   - Does each command succeed? Does each link resolve? Does the verification still work?
   - Fix or delete runbooks that fail; a broken runbook is worse than no runbook

4. Track runbook freshness as a metric
   - "Runbooks updated in last 90 days / total" — target >80%
   - A runbook untouched for a year is almost certainly rotted

5. Delete runbooks for deleted alerts
   - If you delete an alert (alert-fatigue), delete its runbook too
   - Orphan runbooks accumulate and confuse the audit

Example

# runbook/checkout-slo-burn.md (frontmatter)
---
owner: @team-payments      # team responsible for keeping it current
author: @alice             # original author (historical)
last_reviewed: 2026-01-15  # updated quarterly
alert: CheckoutSLOBurnRateFast
---

# Quarterly audit script (run in staging):
for rb in runbooks/*.md; do
  owner=$(yq '.owner' "$rb")
  last_reviewed=$(yq '.last_reviewed' "$rb")
  age=$(( (today - last_reviewed) / 30 ))
  if [ $age -gt 3 ]; then
    echo "STALE: $rb (owner: $owner, last reviewed: $last_reviewed)"
  fi
done
# Output:
#   STALE: runbook/db-failover.md (owner: @team-platform, last reviewed: 2025-08-01)
#   → @team-platform reviews db-failover.md, walks steps in staging, updates or deletes

# Metric: runbooks updated in last 90 days / total = 42/50 = 84% ✅ (target >80%)

Common Problems

⚠No owner — when the system changes, nobody updates the runbook, and the next incident finds a runbook that runs a command that no longer exists.
⚠Owner is a person who left the team — the runbook is orphaned; assign ownership to a team, not an individual.
⚠No quarterly review — runbooks rot silently, and the first test of a runbook is a real incident, which is the worst time to discover it's broken.
⚠Runbooks for deleted alerts linger — they accumulate as orphans, confuse the audit, and waste the reviewer's time.

Best Practices

✓Assign every runbook a team owner (not a person) in frontmatter; the owner keeps it current when their system changes.
✓Make runbook updates part of the system-change checklist; code review rejects changes that break a runbook without updating it.
✓Run a quarterly audit: walk each runbook's steps in staging, fix or delete failures — a broken runbook is worse than no runbook.
✓Track 'runbooks updated in last 90 days / total' as a metric; target >80%, and delete runbooks when their alerts are deleted.