Incident Response Basics
Every team finds out what its incident process is the hard way, usually during the incident. Without one, the first production outage turns into a second problem layered on the first: nobody’s sure who’s supposed to be looking at it, updates to worried users are inconsistent or absent, and the postmortem afterward — if there is one — turns into an argument about who broke it.
None of this needs to be complicated. A workable incident response process for a small team is a handful of decisions made in advance: what counts as an incident, who gets paged, how you communicate while it’s ongoing, and how you talk about it afterward.
Severity levels: not every incident is a SEV1
A useful severity scale is short enough to use under pressure — three or four levels, not a formal ten-point matrix. Something like: SEV1, the whole service is down or a core workflow is broken for everyone; SEV2, a significant feature is broken or a subset of users is affected; SEV3, a minor issue with a workaround available.
The point of naming severity explicitly isn’t bureaucracy — it’s letting the response scale to match the problem. A SEV3 doesn’t need to wake someone up at 2am; a SEV1 does. Without a shared definition, that judgment call gets made inconsistently, under stress, by whoever happens to notice first.
Who gets paged, and a minimal on-call rotation
For a small team, on-call doesn’t need to mean a formal rotation with a dedicated tool from day one — it can be as simple as one clearly-named person per week who owns being reachable if something breaks, with a second person as backup. What matters is that it’s unambiguous: at any given moment, exactly one person should be able to answer ‘is this my problem right now.’
The failure mode this avoids is an incident where three people are half-watching and each assumes someone else has it — which, in practice, means nobody actually does.
Communicating during an incident
Users forgive downtime far more readily than they forgive silence during it. A short, honest update — even ‘we’re aware, we’re looking into it’ with no further detail yet — sent through a status page or a support channel does more for trust than staying quiet until there’s a full explanation ready.
Atlassian’s incident response guidance frames this as a defined role in itself worth assigning during a bigger incident: someone whose job is communication, separate from whoever’s actually fixing the problem, so the fix doesn’t get slowed down by also drafting updates.
Blameless postmortems
The point of a postmortem is to change what the system allowed to happen, not to find the person who happened to be holding the pager. Google’s SRE book describes blameless postmortem culture for exactly this reason: an engineer who expects blame will — reasonably — start being less forthcoming about what actually happened, which is the opposite of what makes a postmortem useful.
A workable postmortem answers a small number of questions honestly: what happened, in what order; what was the actual user impact; what will change so this specific failure is harder to repeat. That last question is the one worth protecting — a postmortem that produces no changed process or code was, in a real sense, wasted.
Frequently asked questions
What actually counts as an incident?
Anything that meaningfully degrades the service for real users — not every error log or minor blip. A useful rule of thumb: if a user would notice and be annoyed, it’s an incident; if it only shows up in a dashboard and nobody outside the team would ever know, it’s a bug to fix on a normal timeline instead.
Does a small team need a public status page?
It’s worth having once you have external users who’d otherwise have no way to know you’re aware of a problem. Even a very simple one — a single page saying what’s currently affected — reduces the number of ‘is it just me’ messages you get during an incident and buys goodwill during it.
What makes a postmortem blameless?
Focusing on the system and the process that allowed a failure, rather than on the individual who happened to trigger it. The test is simple: could this incident have happened to any competent person on the team, given the same information and the same system, on that day? Usually, yes — and that’s exactly what the postmortem should be fixing.
Can on-call work with just two people?
Yes, and for a very small team it often has to. The minimum viable version is one primary and one backup, with a clear handoff so it’s never ambiguous whose turn it is. It gets harder to sustain long-term with only two people, but it’s a legitimate starting point.
Explore the full desk on the home page →
Sources: Google SRE Book — Postmortem Culture · Atlassian — Incident Response — all accessed 4 August 2026.
One concierge, many modes
Learn it, apply it, go further — this page, your way.
Learn it (4)
Apply it (4)
Go further (4)
Terms used on this page
Tap any term for this site’s own definition — no search, no leaving the page.