The First 5 Minutes: An Incident Triage Checklist

The page fires at 2:14 AM. You’re half awake, the graph is doing something ugly, and there are already six messages in the channel asking “is anyone looking at this?” What you do in the next five minutes sets the tone for everything that follows. Handle the opening well and the incident stays coordinated and calm. Fumble it and you spend the next hour untangling the confusion you created in the first three.

After a couple of decades of on-call, I’ve come to treat the first five minutes as its own skill, separate from the debugging that follows. Triage isn’t fixing. Triage is answering four questions fast — what’s broken, how bad is it, who needs to be here, and who’s coordinating — so that the fixing can start on solid ground. Here’s the checklist I run every single time, plus the reasoning behind each step.

Triage is not the fix

The single biggest first-five-minutes mistake is diving straight into the logs. It feels productive. It is not. If you start debugging before you’ve established impact and pulled in the right people, you end up as a lone engineer deep in a stack trace while nobody has told customers anything, nobody knows how bad it is, and the one person who owns the failing service is still asleep because nobody paged them.

Triage buys you a coordinated response. Spend five minutes setting that up and you’ll get the time back tenfold. Skip it and you pay for it for the next hour.

The first-five-minutes checklist

Copy this into your runbook, your incident channel topic, wherever your responders will actually see it at 2 AM.

INCIDENT TRIAGE — FIRST 5 MINUTES

[ ] 1. ACKNOWLEDGE the page. Stop the escalation clock so it
       doesn't wake the next three people while you're already on it.

[ ] 2. OPEN a dedicated incident channel. Not a thread, not a DM.
       One place, named clearly (e.g. #inc-2026-checkout).

[ ] 3. ESTABLISH IMPACT in one sentence.
       "What is the customer experiencing, and how many of them?"
       If you can't answer, that's your first investigation task.

[ ] 4. SET a working severity. Err high; you can downgrade.
       (See your SEV rubric — SEV1/SEV2 page now, day or night.)

[ ] 5. DECLARE who is coordinating. Say it out loud:
       "I'm running point on this." No ambiguity.

[ ] 6. PAGE the owning team if it isn't yours. Don't hero it solo.

[ ] 7. POST a first status line and a comms cadence.
       "Investigating elevated checkout errors. Next update in 15 min."

[ ] 8. START the timeline. First timestamped note goes in now.

Eight items, five minutes, in order. Let me walk the ones that people most often get wrong.

Acknowledge before you investigate

Acknowledging the page does one important thing: it stops your alerting tool from escalating to the next person in the chain. If you skip this because you’re eager to look at the problem, you’ll have three groggy colleagues joining in ten minutes wondering if anyone’s on it. Ack first. It takes two seconds and it prevents a small crowd from forming.

Impact in one sentence, and be honest if you don’t know

The impact sentence is the load-bearing wall of the whole response. “Checkout is returning 500s for what looks like all users” is a completely different incident from “one internal dashboard is slow.” If you genuinely cannot state impact yet, don’t guess — make establishing impact your explicit first task and say so: “Impact unknown, confirming blast radius now.” Naming the uncertainty is far better than inventing false confidence in either direction.

Set severity high, then downgrade

In the first five minutes you’re working with partial information, and under partial information you round up. It is cheap to stand down extra responders once you confirm the blast radius is small. It is expensive to lose fifteen minutes because you called a SEV1 a SEV3 and the right people stayed asleep. Declare based on what you know now, and re-classify freely as facts arrive.

Say who’s coordinating, out loud

Incidents with no clear coordinator turn into a crowd, and crowds are slow. You don’t need a formal incident-commander ceremony for a small issue — you need one human to say “I’ve got coordination on this” so everyone else knows where decisions land. On a small team that same person may also be doing the fixing at first; that’s fine, as long as the coordination role is named and gets handed off cleanly once a second responder shows up.

The comms cadence buys you quiet

Step seven — posting a cadence — is the one most likely to get skipped, and it’s one of the highest-leverage things you do. When you announce “next update in 15 minutes even if nothing’s changed,” you’re making a promise that stops stakeholders from pinging responders every ninety seconds. Silence during an incident breeds anxiety, and anxious people fill the silence by interrupting the people trying to fix it. A predictable drumbeat of updates — even a boring “still investigating, no change” — is what keeps the channel calm enough to work in.

A template for that first line:

🔴 INVESTIGATING — [what's affected], [rough impact].
Working severity: SEVx. Coordinating: [name].
Next update: [time, ~15 min out].

What to deliberately not do in the first five minutes

Don’t root-cause out loud yet. Early theories stated with confidence become anchors the whole team fixates on. Hold hypotheses loosely and say “one thing we’re checking is…” rather than “it’s the database.”
Don’t make risky changes solo. The first five minutes is for assessment. A rushed “fix” applied before you understand impact can turn a SEV2 into a SEV1.
Don’t wait for certainty to pull people in. If you’re wondering whether to page the owning team, page them. An unnecessary page costs someone ten minutes; a missing responder costs the incident an hour.
Don’t let the channel sprawl. Keep one incident channel. Debugging that fragments across DMs and threads becomes invisible to whoever’s coordinating.

Where AI can shave time off triage

The triage minutes are mostly about structuring messy signal fast, which is exactly where a model helps — as a second pair of eyes, never as the decision-maker. You can paste the firing alerts and affected components and ask it to suggest a working severity with its reasoning and what additional signal would change the call, so you know what to go measure. You can also hand it the first burst of channel chatter and have it draft the opening status line in the right register while you keep triaging. The human owns every classification and every message that goes out; the model just helps you move faster in the seconds that matter most. The Incident Response tool turns raw symptoms into a structured first assessment for exactly this window.

Practice the opening, not just the fix

The first time someone runs the opening of an incident should not be during a real SEV1 at 2 AM. Run gamedays where responders practice just the first five minutes — ack, channel, impact, severity, coordination, page, comms, timeline — against a simulated alert, then stop. It’s a short drill and it builds the muscle memory that makes the real thing feel routine instead of frantic. The teams that stay calm in a crisis aren’t calmer people; they’ve just rehearsed the opening enough that it runs on autopilot.

Wrapping up

The first five minutes aren’t about solving the incident. They’re about setting up a response that can solve it — impact established, severity set, the right people present, one clear coordinator, a comms cadence promised, and the timeline started. Get that scaffolding up fast and the debugging that follows happens in a calm, coordinated room instead of a noisy scramble. Print the checklist, put it where your on-call will see it half-asleep, and run it every time until it’s reflex.

AI-assisted severity and comms suggestions are advisory drafts. The on-call engineer owns every call and every message.