A useful runbook works under pressure.

Start with the situation

The first lines should explain the service, the symptom and who might be affected. Include links to the relevant monitoring views and the last known healthy baseline. Avoid dumping a hundred unrelated commands into the opening section.

Prefer read-only diagnosis first

Ask whether the alert is still firing, whether the problem is global or isolated and what changed immediately before the symptoms. Distinguish evidence from assumptions.

• Confirm the signal and its time window.
• Check whether the service remains accessible from more than one vantage point.
• Inspect the most recent deployment or dependency change.
• Record what is known before choosing a disruptive action.

Make actions explicit

An operation that restarts a service or changes routing should identify its expected effect and risks. If the fix cannot be verified, the runbook should say to stop and escalate rather than repeat a destructive action.

Leave a useful record

Capture a compact timeline of observations, decisions, outcome and remaining unknowns. Future responders need the facts, not a performance of certainty.