Most incident response advice is written for companies with dedicated on-call rotations, incident commanders, and postmortem templates nobody on a five-person team has time to fill out. That doesn't mean small teams get to skip incident response — it means they need a version that fits in the margin of an actual outage, not a wiki page nobody reads until it's too late.
Here's the version that fits. Five steps, in order, every time something breaks.
1. Confirm it's real before you act on it
The first minute of almost every incident is wasted arguing about whether it's actually happening. A single monitor flapping can mean a real outage or a network blip on the checking side. Check whether more than one signal agrees — another monitor, a teammate's report, your own browser — before you start treating a maybe as a definitely.
2. Say something before you fix anything
It feels backwards to pause and communicate before diving into a fix, but a thirty-second "we see it, investigating" message — internally, and on a status page if customers are affected — buys you the quiet to actually work. Without it, you're debugging while also fielding five people asking if you've seen it yet.
3. Stop the bleeding before you find the root cause
Rolling back a bad deploy, restarting a stuck service, or failing over to a backup is almost always faster than diagnosing the exact root cause under pressure. Root-causing matters — just not before you've gotten users back to a working state. Mitigate first, understand later.
4. Confirm recovery with the same signal that caught it
If a monitor caught the outage, don't call it resolved until that same monitor agrees. "Looks fine when I click it" and "the automated check has passed three times in a row" are different levels of confidence — use the stronger one before you tell anyone it's over.
5. Write down what happened while you still remember it
Not a formal postmortem — five sentences, written the same day: what broke, what you noticed first, what fixed it, and one thing you'll change so it's either less likely or easier to catch next time. Six months from now, that paragraph is worth more than the incident itself.
The part that makes this actually happen
None of this works if step one — confirming it's real — takes ten minutes because you're staring at raw logs instead of a clear signal. That's the part monitoring is actually for: giving you a fast, trustworthy "yes, this is real" so the other four steps can happen while it still matters. A status page you can update in one click covers step two. An incident timeline that logs itself covers step five before you've even started writing. The checklist is simple; the tooling just needs to get out of its way.