An incident response runbook template for engineering teams under twenty

Key takeaways

• You don't need an SRE team to run incidents well. You need one page: a severity ladder, named roles, comms scripts, a rollback rule, and a postmortem loop. This article gives you that page to copy.
• The person coordinating an incident should not also be fixing it. PagerDuty's model is blunt: "The Incident Commander is NOT a resolver" (PagerDuty).
• Postmortems must be blameless or people hide the truth and you learn nothing. As Google's SRE book puts it, "You can't 'fix' people, but you can fix systems and processes" (Google SRE).
• Downtime is expensive enough to justify the hour it takes to write this. For over 90% of mid-to-large enterprises, an hour of downtime now costs more than $300,000 (ITIC, 2024).

TL;DR

A small team's incident runbook fits on one page. When something breaks, you need to answer five questions fast: how bad is it (severity), who's coordinating and who's fixing (roles), what do we tell people (comms), how do we make it stop (mitigate, usually rollback), and what do we change so it doesn't happen again (blameless postmortem). Big-company frameworks like Google SRE and PagerDuty are excellent, but they assume headcount you don't have. This is the right-sized version: the same principles, collapsed to what a team of five to twenty can actually execute at 2am.

What is an incident runbook, and why does a small team need one?

A runbook is the pre-agreed answer to "what do we do when it breaks," written down before you're panicking. Small teams skip it because incidents feel rare, but that's exactly the problem: when they're rare, nobody remembers what to do, and the response is improvised under pressure. The cost of that improvisation is real. For more than 90% of mid-to-large enterprises, a single hour of downtime now exceeds $300,000, and 41% put it between $1M and $5M or more (ITIC, 2024). Even at a fraction of those numbers, an hour of fumbling is worth avoiding.

The good news: the hard part is deciding, not writing. Once your team agrees on severity levels, roles, and a rollback rule, the document itself is short. Most enterprise runbook advice targets dedicated SRE and ops teams; the small-team version keeps the same bones and cuts the ceremony.

When is it actually an incident? Build a severity ladder

Decide severity first, because everything else keys off it. Without a shared definition, every bug feels like a fire or nothing does. Borrow the widely used three-level model from Atlassian's incident handbook and keep it that simple: SEV1 is a critical incident with very high impact, like a service down for all customers or a data or security breach; SEV2 is a major incident with significant impact, like a service degraded or down for a subset of customers; SEV3 is a minor incident with low impact (Atlassian). SEV1 and SEV2 mean you page someone now; SEV3 waits for working hours.

If you want a sharper trigger for "is this worth escalating," Google's SRE book offers three questions: do you need a second team to fix it, is the outage visible to customers, and is it still unresolved after an hour of focused effort? If any answer is yes, declare an incident (Google SRE). Writing "yes to any of these = declare" into your runbook removes the hesitation that wastes the first fifteen minutes.

Who does what when your whole team is five people?

Split coordination from repair, even if that's the only role distinction you make. The single most important rule in incident response scales down perfectly: the person running the incident is not the person fixing it. PagerDuty states it directly, "The Incident Commander is NOT a resolver," and defines the IC as "the single source of truth of what is currently happening and what is going to happen during a major incident" (PagerDuty). Google's SRE model separates the same concerns into an Incident Commander, an operations lead who does the actual fixing, and a communications lead (Google SRE).

For a team under twenty, collapse that to two or three hats, assigned at declaration time:

• Incident Commander (IC): coordinates, decides, keeps the timeline, and shields the fixer from interruptions. Does not touch the keyboard.
• Fixer (Ops Lead): the only person changing the system. Google's guidance is that the ops team "should be the only group modifying the system during an incident" (Google SRE), which prevents two people from making conflicting changes and confusing everyone.
• Comms/Scribe: posts updates to customers and stakeholders and records the timeline. On a tiny team the IC can wear this hat too, but name it so it doesn't get dropped.

The point isn't titles. It's that nobody has to wonder who's in charge, and the person debugging isn't also fielding "is it fixed yet?" every ninety seconds.

What should the runbook actually contain?

Six sections, no more. Here's a template you can paste into a wiki page and fill in tonight. Everything a responder needs should be reachable from this one page.

Keep contact details, the rollback command, and the status-page login in or linked from this page. At 2am, hunting for credentials is how a ten-minute incident becomes an hour.

How do you communicate during an incident?

Communicate on a fixed cadence with a simple template, so nobody has to compose prose while a system is on fire. Two audiences matter: your internal responders and your affected customers. Internally, post a short update to the incident channel every 15 to 30 minutes even if the update is "still investigating, no change." Silence reads as chaos. A scribe recording the timeline as it happens, the pattern PagerDuty assigns to that role (PagerDuty), makes the postmortem trivial to write and settles any "who did what when" questions later.

For customers, keep a fill-in-the-blank status template ready:

The specific words matter less than having them prewritten. A template turns customer comms from a stressful writing task into a thirty-second fill-in.

How should a small team roll back safely?

Default to rollback first, and let exactly one person make changes. Most incidents on small teams trace to the last deploy, so the fastest mitigation is usually to undo it, not to debug forward while customers wait. Put the exact rollback command in the runbook so it's muscle memory. The discipline that makes rollback safe is the same one from the roles section: the fixer is the only one modifying the system (Google SRE), and they announce each change before making it. When two people both "just try something," you can no longer tell which action helped or hurt, and you've turned one incident into a debugging mystery.

Mitigate first, diagnose later. Restoring service is the priority; understanding the root cause is what the postmortem is for. This maps to the recovery phase of the classic NIST incident lifecycle, Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity (NIST SP 800-61). That framework is written for security incidents, but the shape, prepare, detect, contain, learn, is exactly right for operational ones too.

Why must the postmortem be blameless?

Because blame makes people hide information, and hidden information is how the same incident happens twice. This is the part small teams skip most and regret most. A postmortem, in Google's definition, is "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring" (Google SRE). The blameless part is non-negotiable: focus on the contributing causes, not on indicting a person, because as the SRE book puts it, "You can't 'fix' people, but you can fix systems and processes" (Google SRE).

For a small team, keep it lightweight but real. Within 48 hours of a SEV1 or SEV2, write a one-page doc: timeline, impact, root cause, and, most importantly, follow-up actions with a named owner and a due date. Actions without owners are wishes. The fourth DORA metric, "failed deployment recovery time," the time to recover from a deployment that fails and needs intervention (DORA), is the number the postmortem loop actually improves over time. Track it and you'll see the runbook working.

What we got wrong: For a long time our incidents had no named commander. Whoever noticed the problem started fixing it, other people piled in with their own theories and their own changes, and nobody was talking to the customer. One outage dragged on because two engineers were simultaneously "helping" and quietly undoing each other's changes. The fix cost nothing: we wrote a one-page runbook, and the first rule was "whoever declares the incident is IC until they hand it off, and the IC doesn't touch the code." The next incident was calmer, shorter, and had a clean timeline we could actually learn from.

An incident response checklist for small teams

If your team can check all of these, you're ready for the next one.

1. Severity ladder written down (SEV1/2/3) with clear "declare an incident when…" triggers.
2. Roles defined: IC coordinates, one fixer changes the system, someone owns comms.
3. One-page runbook with the rollback command, contacts, and status-page access linked from it.
4. Comms templates prewritten for internal cadence and customer status updates.
5. Rollback-first mindset; one change at a time, announced.
6. Blameless postmortem within 48 hours for SEV1/2, with owned, dated action items.

Frequently asked questions

How long should a small team's runbook be?

One page. If it's longer, nobody reads it at 2am. The goal is a document a responder can scan in thirty seconds: severity ladder, who's IC, the rollback command, and where to post updates. Depth belongs in linked service docs, not in the runbook itself. Google's and PagerDuty's fuller frameworks are worth reading to design it (PagerDuty), but your live runbook should stay short.

Do we need an incident commander if we're only five engineers?

Yes, arguably more than a big team does. The IC role exists to stop coordination and repair from colliding, and small teams collide easily because everyone jumps in. PagerDuty is explicit that the IC "is NOT a resolver" (PagerDuty); one person coordinates while one person fixes, even if those are your only two roles.

What counts as an incident worth declaring?

Use a simple trigger: declare if you need a second person or team, if it's customer-visible, or if it's unresolved after an hour of focused effort (Google SRE). Under-declaring is the more common mistake; a declared SEV3 that turns out minor costs little, while an undeclared SEV1 costs you the first, most valuable minutes.

How do we run postmortems without blame on a small team where everyone knows who deployed?

Frame every finding as a system gap, not a personal error. If a bad deploy caused it, the postmortem question is "why did our process let a bad deploy reach production," not "why did Sam deploy it." The SRE principle holds at any size: fix systems and processes, not people (Google SRE).

Start with one page

Incident response has an enterprise reputation, but the small-team version is genuinely simple: agree on how bad is bad, decide who coordinates versus who fixes, prewrite what you'll say, roll back first, and hold a blameless postmortem that ends in owned action items. Copy the template above, fill in your service's specifics, and put it where a half-asleep engineer can find it. The next incident will be shorter, calmer, and something you actually learn from, which is the entire point.

If you're standing up incident practices for a growing team and want them right-sized rather than copied from a thousand-engineer playbook, that's exactly the kind of operational foundation we help teams build.