Most teams have an incident channel and a status page. Fewer have a runbook that names the roles, sets the communication cadence, and survives a real outage. Use this template to put that discipline in place without inventing it from scratch.

Download Markdown template Generate a runbook in your browser

What a good incident runbook covers (and omits)

It names the roles (Incident Commander, Tech Lead, Comms, Scribe) and who can fill them. It defines severity levels by user impact and scope. It sets the cadence for updates and who approves external messages. It links the tooling you actually use: dashboards, logs, ticketing, and on-call rotation.

It omits policy essays and vague aspirations. A runbook is not a postmortem template, a compliance statement, or a service owner’s manifesto. It is a checklist the team can run under pressure.

Severity matrix showing SEV1–SEV4 against impact scope
Calibrate severity by scope of impact, not by personal stress level.

Template sections (copy‑paste)

These are the sections we include when we operate client environments. The Markdown download above contains the same structure with placeholders.

  • Scope: which systems and data this runbook covers.
  • Triggers: which alerts or conditions open an incident.
  • Severity levels: SEV1 to SEV4 with concrete thresholds.
  • Roles: IC, Tech Lead, Comms, Scribe, and common SMEs.
  • Communications: channels, cadence, and approval flow.
  • Tooling: links to dashboards, logs, paging, and tickets.
  • Standard response: acknowledge, stabilize, diagnose, fix, close.
  • Escalations: when to involve leadership, vendors, or security.
  • Exit criteria: what “resolved” means operationally.
  • Post‑incident review: evidence to collect and questions to answer.

Communication templates by severity

Script the first update, the follow‑ups, and the resolution note. Consistency beats wordsmithing under pressure.

Communication cadence blocks for SEV1–SEV3 across initial, updates, and resolution
Set a default cadence. Break it explicitly if facts warrant.

SEV1 initial (15 minutes)

Subject: [SEV1] Service outage: investigating
Body: We are investigating an outage affecting scope/users. Next update in 15 minutes or sooner if material change. Reference: INC‑1234.

SEV2 initial (30–60 minutes)

Subject: [SEV2] Service degraded: triaging
Body: We are triaging elevated errors/latency affecting subset. Next update in 30–60 minutes. Reference: INC‑5678.

Resolution

Subject: Service incident resolved
Body: Impact window start–end, cause short cause, actions taken, and prevention items (review to follow).

Worked example: SaaS API outage

Trigger: 5xx above 10% for 5 minutes; multiple customer reports. Severity: SEV1. Roles: IC=A. Lee; Tech Lead=J. Patel; Comms=K. Nguyen; Scribe=M. Ortiz.

  • 00:03: roll back deploy 2026‑08‑26.2; error rate drops to 4%.
  • 00:06: scale API pods +2 per AZ; latency returns to baseline.
  • 00:12: investigate DB CPU spikes; revert index migration.
  • 00:20: resolved; resolution note prepared; follow‑ups filed.

Worked example: Security event

Trigger: EDR flags lateral movement attempt on app server. Severity: SEV2 (escalate to SEV1 if confirmed compromise). Roles: IC=B. Smith; Tech Lead=R. Zhao; Comms=J. Ali; Scribe=H. Cohen.

  • Isolate host from network; snapshot disk and memory.
  • Rotate credentials for affected services.
  • Review logs for data exfil; prepare customer notice if required.
  • Coordinate with Legal for wording and retention.

How to test a runbook and keep it current

Run a tabletop monthly for 45 minutes. Pick a realistic trigger, assign roles, and practice the first thirty minutes. Time‑box the drill, then capture what was missing and fix it immediately. Tie the runbook to change hooks: a deploy that changes the failure surface (auth, database, network) should flag a runbook review.

When incidents happen for real, update the template the same day you close the ticket. Small edits beat annual rewrites.

Prefer a guided flow? Generate a runbook and export Markdown or Word.