Runbook Template for Product Managers

Detailed enough that someone who has never performed this procedure can execute it at 2 AM with no assistance. Include exact commands, expected outputs, and verification steps. If a step requires judgment (e.g., "evaluate whether the system is healthy"), define what "healthy" looks like with specific metrics or outputs.

Automate the procedure. Keep the runbook for when automation fails. Automated runbooks (scripts, Terraform, Ansible) are faster and less error-prone. But automation breaks. When it does, the on-call engineer needs the manual procedure documented. Write the manual runbook first, then automate, and maintain both.

Three practices: (1) Test runbooks on a quarterly schedule in staging. (2) Update the runbook every time it is executed and a step is wrong. (3) Assign an owner to each runbook who is responsible for quarterly review. The [internal wiki template](/templates/internal-wiki-template) provides the governance framework for keeping documentation current.

In the same system your on-call team uses during incidents. If that is a wiki, put them there. If that is a Git repo, put them there. The critical requirement is that runbooks are accessible during an outage. If your wiki goes down when the database goes down, your database failover runbook is inaccessible exactly when you need it. Consider keeping critical runbooks in a backup location (printed, or in a separate availability zone).

Interview the person who has done it. Have them walk through the procedure while you document every step, command, and decision. Then execute the procedure yourself in a staging environment using only the runbook. Every step where you pause or get confused needs more detail. The [documentation standards template](/templates) provides additional guidelines for writing clear procedural content. ---