| name | pc-runbooks |
| description | Use when an operational task or incident needs a concrete step-by-step procedure that another responder can execute safely, especially when rollback, fail-closed containment, coexistence fallback, communication cadence, or evidence capture must be explicit under pressure. |
| metadata | {"phase":"07-operations","inputs":["incident-playbook","monitoring-config","ci-cd-pipeline"],"outputs":["operational-runbook","escalation-checklist"],"prerequisites":["pc-incident-response"],"quality_gate":"Runbook contains trigger, decision points, execution steps, verification checks, rollback or fail-closed path, and communication guidance","roles":["devops-engineer","tech-lead"],"methodologies":["all"],"effort":"medium"} |
Runbooks
A good runbook lets a competent responder do the right thing without improvising under stress.
Context
Runbooks convert operational knowledge into executable procedures.
See context and anti-pattern notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Define the Trigger and Owner
Specify:
- what alert or symptom activates the runbook
- who is expected to start it
- what severity range it applies to
- when to escalate instead of continuing solo
Step 2: Capture Preconditions and Safety Boundaries
Before the first action, state:
- what must be true before executing the procedure
- which paths must be preserved
- what should fail closed if the system is unsafe
- whether rollback or fallback is preferred over partial manual repair
- where any referenced threshold, policy, or guard decision comes from
Step 3: Write the Response Steps
Use numbered steps with:
- exact decision points
- commands, dashboards, or checks to use
- expected observations
- branch conditions for rollback, fallback, or escalation
- explicit source or value for any threshold like "communication threshold" or "expected recovery window"
Avoid prose that forces the reader to infer the next move.
Step 4: Add Verification and Communication
A runbook must say:
- how to confirm the mitigation worked
- which metrics or logs prove recovery
- who gets updated and how often
- what evidence should be captured for post-incident follow-up
Step 5: Keep the Runbook Executable
Validate that someone other than the author can follow it. Update the runbook after incidents, failed drills, or major release changes.
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
