The Runbook Deprecation Policy

Old runbooks lie. The policy that retires them before they mislead.

Triggers

Runbook deprecation only happens when something forces it. Time-based and ownership-based triggers auto-flag stale runbooks for review without depending on humans to remember.

• Last touched over 12 months. Staleness signal per runbook. Drives the first auto-flag.
• Last referenced over 6 months. Unused signal per runbook. May still describe a real system, but nobody reaches for it.
• Service retired. Dependency-deletion trigger per runbook. Linked service goes away; runbook follows.
• Auto-flag visible in the system. “Needs review” badge per runbook. Catches drift without manual audits.

Review

Review is the explicit decision point. The named owner updates or retires; default is retire after a short grace window so “I will get to it” does not stall the process indefinitely.

• Owner reviews each flagged runbook. Named-owner check per runbook. Update or retire.
• Decision required. Explicit choice per runbook. Avoids the “I will get to it” stall.
• Default retire after 30 days. No-action default per runbook. Drives forced decisions.
• Audit log. Timestamped record per decision. Supports later “what happened to X runbook” questions.

Avoid

The recurring failure modes are visible at every postmortem: runbooks naming engineers who left in 2023, references to tools that no longer exist, dependencies on services that retired. Stale runbooks are worse than no runbook because they actively mislead new responders.

• Runbooks naming departed engineers. “See Bob if confused” pattern per runbook. Bob left in 2023.
• References to deprecated tools. Dead-tool mention per runbook. Confusing during real incidents.
• References to retired services. Orphan dependency per runbook. Misleads new responders.
• Freshness banner. “Last verified on X” header per runbook. Supports trust in the doc.