Here's a small thing that quietly wrecks incident response: nobody agrees on what "SEV1" means.
To one engineer it's "the whole site is down." To another it's "I'm stressed and this feels bad." When severity is a feeling instead of a definition, everything downstream misfires — who gets paged, how fast, who's told, and whether the CEO hears about it before or after a customer does.
The fix is boring and it works: define severity by customer impact, written down, before you need it.
SEV1 - major outage, data loss, or security breach; most users affected. All-hands, page leadership.
SEV2 - a key feature is down or degraded for many users. Urgent, within minutes.
SEV3 - limited impact, a workaround exists. Same business day.
SEV4 - cosmetic, no user impact. Next business day.
Notice what the definition keys on: customer impact - not how hard the fix is or how the responder feels. That single anchor makes the rest of the process fall out automatically: response time, who's involved, what you tell customers.
Two rules that make it stick:
Anyone can declare; the commander decides. A low bar to open an incident means you catch things early - you can always downgrade.
Never let a SEV1 be the first time leadership hears about a risk. Surface early, with your plan. Executives forgive problems; they don't forgive being blindsided.
Write the matrix once, put it where the on-call engineer will find it at 2am, and you've removed the single biggest source of incident chaos.
The Incident & On-Call Ops Kit gives you the whole system - severity matrix, on-call policy, a 2am runbook, blameless postmortem, and comms templates - wired together. It's at ctofieldkit.com.