runbooks.

Where runbooks fits on a long engagement.

A good runbook is written for someone who does not understand the system. It gives exact commands, expected output, and the decision to make at each branch. A runbook saying "check the database is healthy" is a note to someone who already knows; one giving the query, the threshold and the action is usable by whoever is on call.

Runbooks decay faster than any other documentation because the systems they describe change constantly. A procedure referencing a decommissioned dashboard actively wastes time during an incident, which is worse than its absence — the responder follows it, finds nothing, and has lost five minutes.

What an assigned team does with runbooks.

The only reliable way to keep runbooks true is to use them. Following the runbook during every incident, and correcting it immediately afterwards, is the practice that works; a scheduled review that nobody does is the one that does not.

Building that habit into incident response is part of how operational responsibility is held, as described in how an assignment runs.

What we use runbooks for.

• Response that does not depend on one person Procedures anyone on call can follow, with exact commands and expected output.
• Corrected as a matter of course Updated during the incident that revealed the gap, not at a review nobody schedules.
• A path toward automation Well-specified procedures becoming scripts, because the steps are already unambiguous.

How runbooks capacity is assigned.

Operational documentation is part of platform capacity assigned under devops as a service, maintained through use rather than by periodic review.