Roles (even for a team of three)
- Commander. Runs the incident: decides, delegates, keeps time. Does not debug.
- Responder(s). Investigate and fix. Report findings to the commander, don't freelance.
- Communicator. Updates the status page and stakeholders. Keeps responders interruption-free.
- One person can hold two hats in a tiny team — but the commander hat never debugs.
Severity levels
- SEV-1: Core functionality down for all or most users. All hands, immediate.
- SEV-2: Major feature degraded or partial outage. Urgent, business-hours-or-paged depending on impact.
- SEV-3: Minor degradation or cosmetic issues. Fix in normal workflow.
- Define yours with examples from your own product — abstract levels get misapplied under stress.
The first 15 minutes
- Declare the incident and severity — say it out loud in the channel.
- Assign commander, responders, communicator explicitly.
- Mitigate first, root-cause second: stop the bleeding (rollback, failover, scale) before the autopsy.
- Start a timeline log immediately — every action timestamped. Memory lies; logs don't.
The postmortem habit
Every SEV-1 and SEV-2 gets a blameless postmortem within a few days: timeline, root cause, what went well, and action items with owners and dates. The postmortem's value isn't the document — it's the action items actually getting done. Track them like product work, because they are.
Assumptions and limits
- Template is guidance; adapt roles and severities to team size.
Common questions
What should a small team incident runbook include?
Named roles (commander, responders, communicator), severity levels with product-specific examples, the first-15-minutes sequence, communication templates, and the postmortem process. The commander runs the incident — decides, delegates, keeps time — and never debugs; the communicator updates the status page and stakeholders so responders stay interruption-free. One page beats a wiki nobody reads mid-incident.
Should we fix or mitigate first during an outage?
Mitigate first — rollback, failover, or scale to restore service — then investigate the root cause. Stop the bleeding before the autopsy: declare the incident and severity, assign the roles explicitly, and start a timeline log immediately, because memory lies and logs don't. Users care about restoration time, not about how cleverly you diagnosed while they waited.
Are postmortems worth it for small teams?
Yes — they're the highest-leverage reliability practice available. Every SEV-1 and SEV-2 gets a blameless postmortem within a few days: timeline, root cause, what went well, and action items with owners and dates. A 30-minute blameless review producing two owned action items prevents more future downtime than most tooling purchases — the value is the items getting done.
Published · Updated . Availability planning guides for small web teams. Models are planning tools, not guarantees.
Sources: Google SRE Book: Managing Incidents — incident command roles, the living incident document and postmortem practice. The template above is guidance; adapt roles and severities to team size.
The next outage is a matter of when.
Be the team with the plan: a one-page runbook with named roles, severity levels, and the first-15-minutes sequence.