Incident Response Playbook for Small Teams

Small teams rarely have a dedicated incident commander, a NOC, or a 24/7 SRE rotation - but outages don't wait for you to have one. A lightweight, written incident response playbook turns chaotic 2am Slack threads into a repeatable process, even with three engineers sharing on-call duty.

Why small teams need a playbook

Without defined roles and steps, incidents at small companies tend to follow the same failure pattern: everyone jumps into the same thread, nobody owns customer communication, and the actual fix gets delayed because two people are debugging the same thing without coordinating. A playbook doesn't require headcount - it requires five printed pages everyone has read once.

Minimal roles for a 3-10 person engineering team

You don't need six named roles. Two or three is enough:

For teams under 5 engineers, one person often plays IC and Responder simultaneously - that's fine, as long as someone is still handling comms so the fix isn't interrupted by support tickets.

Severity matrix

Define severity before an incident happens, not during one:

The first 15 minutes

This is the checklist that matters most - print it, pin it, put it in your runbook repo:

• Acknowledge the alert within 5 minutes
• Confirm it's real (check uptime monitoring dashboards and recent deploys, not just one data point)
• Assign an Incident Commander out loud, even if it's just you
• Open a dedicated incident channel (#inc-2024-06-12-checkout), not the general channel
• Post an initial status update - internally and on your status page if customer-facing
• Check for recent deploys, config changes, or expired certificates as the likely cause
• Start a timeline document immediately - you will not remember exact timestamps later

Communication cadence

Silence during an incident is worse than bad news. Customers and stakeholders tolerate "we're still investigating" far better than no update at all.

Recommended cadence by severity:

• SEV1: update every 15-30 minutes even if the update is "still investigating, no new information."
• SEV2: update every 30-60 minutes.
• SEV3: one update at detection, one at resolution.

Sample update templates:

[Investigating] We're aware of elevated error rates on the API and
are actively investigating. Next update in 30 minutes.

[Identified] We've identified the cause as a failed database
migration and are rolling back. ETA to resolution: 20 minutes.

[Resolved] The issue has been resolved as of 14:32 UTC. We'll
publish a post-mortem within 5 business days.

Tooling for small teams

You don't need an enterprise incident stack. A minimal but effective toolchain:

• Detection: uptime, SSL, and API monitoring checks that page reliably with confirmation retries.
• Paging: any tool that supports escalation policies and phone calls, not just Slack pings.
• Comms: a public status page separate from your main site (so it stays up even if your infrastructure doesn't) and a private incident channel per event.
• Timeline: a shared doc, updated live, timestamped in UTC.
• Post-incident: a blameless post-mortem template (see our dedicated post on that).

Building the timeline

A good timeline is built during the incident, not reconstructed afterward. Minimum fields per entry:

14:02 UTC - Alert fired: API error rate > 5%
14:04 UTC - IC assigned (Jane)
14:06 UTC - Confirmed real via status page checks, not a false positive
14:11 UTC - Identified recent deploy as likely cause
14:15 UTC - Rollback initiated
14:22 UTC - Error rate back to baseline
14:32 UTC - Incident declared resolved

Escalation without a big team

If the primary responder can't resolve it within a defined window (commonly 30 minutes for SEV1), escalate:

1. Loop in a second engineer familiar with the affected system.
2. If infrastructure/vendor-related, open a support ticket with your cloud provider or third-party API immediately - don't wait until you've exhausted internal options.
3. If unresolved after 60-90 minutes on a SEV1, consider a public acknowledgment that resolution is taking longer than expected, rather than going quiet.

After the incident

Every SEV1 and SEV2 should get a short post-mortem, even for a two-person team. It doesn't need to be a formal meeting - a shared doc with what happened, why, and what changes is enough. The habit matters more than the format.

FAQ

Do we need a formal incident commander for a 2-person engineering team?

You need the role, not necessarily a separate person. One engineer can be IC and Responder simultaneously as long as someone (even a founder) handles customer communication so debugging isn't interrupted.

How often should we update customers during an outage?

Every 15-30 minutes for full outages, every 30-60 minutes for partial degradation, even if there's nothing new to report. Frequent "still investigating" updates build more trust than silence.

What's the minimum severity matrix we should define?

Three levels are enough for most small teams: full outage, partial degradation, and minor/cosmetic. Map each to an update cadence and escalation path before your next incident, not during it.

Should a status page be hosted on the same infrastructure as the product?

No. Host it separately (a static site or a dedicated status page product) so it stays reachable even when your primary infrastructure is down - that's often the only channel customers can reach during a full outage.

Running incident drills before you need them

The first time your playbook gets used shouldn't be during a real SEV1. Small teams often skip drills because they feel like a luxury reserved for larger organizations, but a 30-minute tabletop exercise once a quarter catches gaps cheaply.

A simple drill format:

1. Pick a plausible scenario (database failover fails, a certificate expires unnoticed, a third-party payment API goes down).
2. Walk through the first 15 minutes checklist out loud as a team, without actually touching production.
3. Identify where the playbook was ambiguous - who declares the incident, who updates the status page, what the escalation timeout actually is.
4. Update the playbook document immediately afterward while the gaps are fresh.

Teams that run even one drill a quarter consistently report fewer "who's doing what" delays during real incidents, because the roles already feel familiar rather than theoretical.

Common mistakes small teams make

• No dedicated incident channel. Debugging in the same channel as customer support pings creates noise and slows triage.
• Nobody owns comms. Engineers get pulled out of debugging to answer "is this related to the outage?" questions from support or sales.
• Escalating too late. Waiting an hour to loop in a second engineer or open a vendor ticket, when the playbook should trigger escalation automatically at a defined time threshold.
• Treating every alert as an incident. Not every failed check needs an incident channel and status page update - reserve that for SEV1/SEV2, and let lower severities flow through normal ticketing.
• No timeline until after the fact. Reconstructing timestamps from memory after resolution is unreliable and makes the post-mortem weaker.

Keeping the playbook itself maintainable

A playbook that's 20 pages long won't get read during a real incident. Keep the core document to one page: roles, severity matrix, first-15-minutes checklist, and links to more detailed runbooks for specific systems. Store it somewhere accessible even when your primary tools are down - a wiki page that depends on the same infrastructure that's currently on fire is not a reliable runbook location.