The most common mistakes in incident management

The most common incident management mistakes aren’t technical. Teams wait too long to declare and make people improvise roles at 3am. They chase root cause while customers are still down, then measure the program with an average that hides their worst days. Every one of these is fixable before the next incident starts.

I’ve spent about a decade running incident programs at Braintree, PayPal and Chime, and I’ve made most of these mistakes myself. My favorite was at PayPal, where the enterprise severity matrix was 125 lines long and only existed as a PDF. Every time I tried to delete a line, someone would come crawling to me saying no, that’s my team’s line. We got it down to about 15.

Here are the twelve I see most, and what I’d do instead.

Waiting too long to declare
Asking the reporter to set severity
Letting the incident commander fix it
Deciding roles in the middle of the incident
Chasing root cause before stopping the bleeding
Saying a guess like it’s a fact
Waiting for the cause before posting on the status page
Running on-call with too few people
Asking “why did you do that?”
Averaging MTTR
Treating every action item as a promise
Letting AI make the judgment calls

1. Waiting too long to declare

Most teams declare late because people think they’ll get their wrist slapped for a false alarm. My rule is simple. When in doubt, open an incident. I’d rather get paged a hundred times for something that turns out to be nothing than miss the one that matters.

Declaring should take one Slack command or one button inside the tools people already use. The form should ask what’s wrong and almost nothing else. If someone has to find the right page and fill out six fields first, they’ll wait another twenty minutes to see if it fixes itself (it usually doesn’t).

Do this instead. Write a one-sentence incident definition that anyone from an engineer to the CEO can apply. Then put a declare button or Slack command where people already work.

2. Asking the reporter to set severity

This is a spicy one, and it’s my view more than the industry’s. Most handbooks have whoever declares the incident pick its severity. I think that’s backwards. A 911 caller says “there’s a fire,” not “this is a three-alarm fire.” The reporter’s job is to say there’s a problem. The incident commander (IC) sets severity once they’re paged in and changes it as facts come in.

Courtney Nash’s research on public incident reports (the VOID database) found no link between how long incidents lasted and their severity, and she calls severity “highly subjective” (InfoQ, Feb 2023). Putting a severity scale in front of the reporter adds hesitation and gets you a noisy label anyway.

Do this instead. Take severity off the declare form. The IC sets it in the first few minutes and changes it as facts come in.

3. Letting the incident commander fix it

The incident commander’s job is to run the incident, not to fix it. The moment the IC opens a terminal, nobody is watching the whole picture. Updates stop and two engineers end up trying the same fix. Nobody notices the third team that should have been paged forty minutes ago.

A good IC starts with a roll call (who’s here and what are you looking at?) and keeps every workstream moving with an owner. They also hand off at the four-hour mark, before they’re running on empty.

Do this instead. Give the IC one job. Start every incident with a roll call, put an owner on each workstream, and hand off at four hours.

4. Deciding roles in the middle of the incident

If you’re figuring out who writes the customer update while the site is down, you’ve already lost time. Roles should scale with severity and be written down before anything breaks. My default is that every SEV0 and SEV1 (the two worst severity levels) gets a scribe, and big bridges get a dedicated comms person so engineers never write the status page.

Even on teams that pay for incident tooling, only 11.8% define a role named scribe (across Rootly customers, as of Oct 2026). That’s the role you miss most when you’re three hours into a SEV1 and trying to rebuild the timeline from Slack.

Do this instead. Write a playbook that lists the roles for each severity level. Then practice it in a tabletop exercise before you need it.

5. Chasing root cause before stopping the bleeding

I’ve run hundreds of incidents, and in most of them I’m fighting engineers to stop looking for the root cause. That’s not the goal right now. The goal is ending customer impact, usually by rolling back the most suspicious change.

Wanting to understand the problem is a good instinct at the wrong time. Mitigation ends the impact and learning ends the incident. Root cause is a conversation for the retrospective, when no customers are waiting on you.

If nothing changed recently, look for the quickest way to cut the impact (failing over, turning off a feature flag) before anyone starts digging.

Do this instead. Make the IC’s first question “what can we roll back?” Park root cause theories in the incident notes for the retro instead of chasing them on the bridge.

6. Saying a guess like it’s a fact

Early in an incident everyone has a theory, and the loudest one tends to show up in the exec update as fact. Then it turns out to be wrong, and you’re walking it back in front of customers.

Cloudflare’s Nov 18, 2025 outage is a good public example. Their own status page went down at the same time by coincidence, which pushed the team toward a DDoS theory. The real trigger was a database permissions change (Cloudflare, Nov 2025).

Label what’s confirmed and name what isn’t. My test for any update is whether it would still be true if the leading theory is wrong.

Do this instead. Split every update into “what we know” and “what we’re still checking.” Before it goes out, ask whether it holds up if the leading theory is wrong.

7. Waiting for the cause before posting on the status page

Teams hold the first status page update until they can explain what happened. Meanwhile their customers are refreshing the page and asking support if it’s just them. Google’s SRE Workbook says it well: “Unless you acknowledge that an incident is happening and actively being addressed, people will automatically assume nothing is being done” (Google SRE Workbook).

Post “we’re aware and investigating” right away, from a template Legal approved ahead of time so nobody waits on a sign-off. After that, update every 15 to 30 minutes for high severity and every 45 to 60 for lower severity. Keep posting even when the only news is that you’re still working on it.

Do this instead. Get a “we’re aware” template approved by Legal this week. Give whoever holds the comms role permission to post it without asking anyone.

8. Running on-call with too few people

My rule of thumb is that a rotation needs at least 5 people before it has any slack. Below that, one sick day or vacation turns into someone covering back-to-back weeks. Google’s SRE book recommends 8 for a single site, so I’m on the lenient side here.

Even on teams with dedicated on-call tooling, 17.6% of schedules have just one person and the median sits right at 5 (Rootly benchmark report, Oct 2026). If yours is under 5, add managers and directors to the rotation first, then merge and cross-train teams.

Do this instead. Count the people on each rotation. Ask yourself who covers if two of them are out next week, and fix any rotation where the answer is nobody.

9. Asking “why did you do that?”

People who get blamed stop telling you the truth, and then every retrospective is fiction. Humans don’t cause incidents. The systems that let the incident happen do. The question on the bridge and in the retro is “how can I help,” never “why did you do that.”

My line for individual accountability is narrow. It applies when someone deliberately works around a control for their own gain. Classic just culture also holds people accountable for recklessness. Everything else is a gap in the system.

Do this instead. Ask “how can I help” on the bridge. In the retro, write about what the system allowed rather than who touched it last.

10. Averaging MTTR

Most teams I talk to ask about MTTR first. I understand the appeal, but MTTR is the most misunderstood metric in incident management and it can do real harm. Push hard enough on speed and people skip testing to force a deploy out, which makes the impact worse.

It also mixes incidents that should never be compared. I’ve worked a deploy that was rolled back in a minute and an incident that ran for a year (the wrong terms of service shown to the wrong people). Averaging those two tells you nothing. Across Rootly customers, the median critical incident was resolved in 1.1 hours, but the mean was 9.1 days, according to the same benchmark report.

Instead, sort the last six months by duration and run a full retrospective on the five to ten longest. Find where the time went (triage, waiting for a responder, waiting on Legal) and fix that. Google’s research calls MTTR “poorly suited for decision making” (Google SRE), so I’m not alone on this. I’m just louder about it.

Do this instead. Replace the MTTR slide with three things each quarter: incidents by service or team, incidents by contributing factor, and your three most expensive incidents.

11. Treating every action item as a promise

A retro ends with eight action items and everyone nods. Six months later most of them are still open, and nobody remembers who was supposed to own them.

My view is that action items are possibilities, not commitments. Each one goes to whoever owns that team’s roadmap. They either schedule it or close it with a written reason. Atlassian takes the opposite approach with 4 to 8 week deadlines, and that works for some teams. A backlog nobody ever decides on works for nobody.

Do this instead. Send every action item to the team’s roadmap owner and ask for one of two answers: scheduled, or closed with a written reason.

12. Letting AI make the judgment calls

I use AI every day, and I’m all for it doing the grunt work. Correlating alerts, drafting the timeline for a low-severity retro and running a runbook a human already approved are great jobs for it. Deciding whether to roll back, what severity this is or what goes on the status page are not.

Any AI claim during an incident should show its work and be labeled confirmed or unconfirmed. Confirmed means at least two sources, and one of them is a metrics platform or logs. DORA’s 2025 report has the line I keep coming back to: “AI doesn’t fix a team; it amplifies what’s already there” (DORA 2025).

Do this instead. Write down which actions AI can take on its own (the pre-approved runbook steps) and which always need a human. Then require a confirmed or unconfirmed label on every AI claim.

What good looks like

Every mistake on this list gets made in the moment, under pressure, by people doing their best. The fix is almost always to decide it before the incident. Write it down and practice it, because nobody makes their best call improvising at 3am.

Good incident management means a response that’s calm, fast and predictable. Everyone already knows their job, and the whole thing feels a little boring. If your last SEV1 felt like chaos, pull up its timeline and start with whichever of these twelve shows up first.

(And if you want a second set of eyes on your incident process, shoot me an email.)