Incident Commander Checklist

Most small-team incidents don't fail on skill. They fail on command. Five capable people ping-ponging a problem in one chat channel is a committee, and committees debug slowly, never decide, and talk to customers never. The fix is old and unglamorous: one name is the incident commander (IC), one voice talks to the business, one page runs the show. This checklist is that page — the appointment, the first ten minutes, the cadence, the decisions, and the close-out. It costs nothing and works on every incident you'll ever have.

The five-minute appointment: one name, out loud

The single most common small-team failure is that nobody is in charge because everyone is competent. Competent people dive into the problem. Command is what nobody picks up, because it looks like not helping. So make the appointment mechanical:

• Within five minutes of a declared incident (a Sev-1 or Sev-2 per your severity matrix), exactly one person types in the war-room channel: "I am IC." Three words. Whoever says it first and means it, has it.
• The IC is a role, not a rank. The most junior engineer can command the most senior. Choose by who has the clearest head right now, not the longest title. The CTO debugging a firewall does not also run the incident.
• You can resign the role, once, cleanly. "Passing IC to Ana — she has the state" is allowed and encouraged when your tank hits empty. What's not allowed is command by erosion — three people half-commanding because nobody formally handed off.
• The IC does not touch keyboards. This is the hardest rule and the whole point: the commander's job is to keep the picture whole, sequence the work, and talk to the humans. A commander elbow-deep in logs has stopped commanding and the incident now runs itself. Delegate the work; never perform it.
• Everyone else is a role too. The IC assigns: one comms owner (talks to stakeholders, nobody else does), one scribe (timeline, every event timestamped), and N hands (the people debugging). Roles are named in the channel like "I am IC" — "I have comms", "I'm scribing".

First ten minutes: the card

The IC's opening moves, in order. Print this or paste it into the war-room template:

• Declare once, in writing. One message: what's broken (from the customer's point of view), what severity, and that you're IC. If the incident isn't written down in one sentence, the team is fighting five different incidents.
• Create the war room. One dedicated channel or call — not the channel where the alert fired. Name it like inc-2026-09-26-checkout. Everything about this incident happens there; the IC moves stragglers in.
• Start the timeline. First row: when it started, how we found out (monitor vs customer tweet), what changed in the last 24 hours (deploys, config, vendor updates, volume). The incident timeline template is the format; the scribe owns the rows.
• Name the stop-the-bleeding owner. One person's only job is to reduce harm now — the rollback, the failover, the toggle, the queue pause. Diagnosis is for later; mitigation is for the first hour. Make sure the two don't blur: the question for the first hour is not "why" but "how do we make it stop hurting".
• Send the first stakeholder update inside 15 minutes, even if it says "we know, we're on it, next update at :45". Silence is read as "nobody is home".
• Decide who is decision-money. If this incident might need spend (vendor escalation, hardware, overtime, a status-page provider), say now who can authorize it without hunting for the founder. Default: the IC, up to a pre-agreed cap.

The cadence: every fifteen minutes, out loud

Open-ended "working on it" stretches bend time; two hours vanish while everyone feels busy. The cadence is what keeps an incident honest:

• Every 15 minutes the IC runs a round-robin, sixty seconds each: stop-the-bleeding owner says the current mitigation state; hands say what they're testing and what they've ruled out; comms owner says what stakeholders have been told.
• Then the IC says the decision point: "If X isn't working by 4:00, we roll back." Write it in the channel. A decision point with a deadline is what separates command from watching.
• Every 30–60 minutes (per severity), a stakeholder update goes out with three sections: what we know, what we're doing, next update time. The incident communication templates are pre-written for exactly this — don't draft from scratch at 2 a.m.
• The IC watches the clock, not the logs. If two hands are doing the same thing, or nobody is doing the scariest thing, that's a command failure before it's a technical one.

Six decisions only the IC makes

Committees advise; the commander decides. The ones that must have exactly one owner:

• 1. Mitigate or diagnose. Rollback now with unknown cause, or keep digging for two more minutes? Default for small teams: mitigate first, diagnose after — a root cause without an outage is a Tuesday; an outage with a root cause is still an outage.
• 2. Talk to customers now or wait. Waiting is a choice too, but make it out loud: "no customer comms until we know if card data is affected." See the status page communication template for the pre-staged drafts.
• 3. Spend money. Vendor premium support line, emergency hardware, a taxi for the person with the only working laptop. The IC commits up to the pre-agreed cap; above it, one named founder.
• 4. Wake people up. Calling the person who owns the billing integration is an IC decision, made with the escalation policy in front of you — not a personal favor the night engineer has to dare to ask for.
• 5. Escalate outward. Open the vendor's Sev-1 line, page the MSP, engage the ISP's escalation ladder (with a ticket number and ETAs in writing, per the vendor escalation ladder).
• 6. Upgrade or downgrade severity. Sev-2 that's about to breach a payment deadline becomes Sev-1; Sev-1 contained to one feature downgrades. Declare the change in the channel with one sentence of why.

The hands-off rule, defended

Every commander eventually wants to "just quickly check one log". Resist, because of what happens in the next ninety seconds: the picture goes dark. Nobody is sequencing, the stakeholder update is late, two people are editing the same config, and the customer tweet goes unanswered. In a five-person team the IC's attention is the scarcest resource in the incident — the debugging is parallel, the commanding is not. If there's genuinely nothing to command (one server, one person, an outage so small it fits in a head), then say so and be a single responder instead. The failure mode isn't "commanded too little", it's "commanded and debugged at once".

Closing the incident: mitigated is not resolved

Declare the end in two distinct words, because they trigger two different clocks:

• Mitigated — harm is stopped; customers can transact; risk of recurrence is unknown. The IC's job ends at "mitigated" handoff: war room goes quiet, watchowner keeps an eye for 24 hours, and the after-action report opens with a 48-hour deadline.
• Resolved — root cause known, fix landed and verified, recurrence risk accepted or patched. That is the postmortem's ending, not the IC's. Don't blur them: "resolved" said too early is how the same fire returns in a new costume.
• The IC writes the first timeline draft before the war room closes — not from memory the next day. Ten minutes, timestamps only, no blame. The scribe's rows make this a copy-paste, which is why the scribe exists.
• Thank the roles by name in the closing message. It sounds soft; it's what makes people volunteer for IC next time, and volunteering is what makes the system work at 3 a.m.

Worked example: checkout dark at 14:03

A five-person team, payments failing. The alert fires at 14:03 in the monitoring channel. 14:05, Mo types "I am IC." He has run incidents twice; Ana debugs payments weekly — she is a hand, not the commander. 14:06, war room inc-2026-09-26-checkout; Ana named stop-the-bleeding, Priya scribe, Tom comms. 14:08 the declaration: "Checkout is failing for ~100% of card payments since ~13:50, first found by customer tweet. Sev-1. I'm IC." 14:10, timeline's first rows: yesterday's deploy (13:40), the tweet (13:52), the alert (14:03). 14:12, Ana's first move is the 13:40 rollback candidate — not a packet capture. 14:15, first stakeholder update from Tom: "known, on it, next update 14:45." 14:30 round-robin: rollback staged but the 13:40 build is identical to 13:39 — the deploy isn't the cause. Mo states the decision point: "If no mitigation by 15:00, we switch to manual invoicing mode." 14:44 Ana finds the PSP's maintenance window (13:45–14:40, unannounced) matching the failure perfectly; fail-forward is to hold traffic with a banner. 14:46 comms out to customers via the pre-staged banner; vendor Sev-1 ticket opened with ETAs in writing. 14:52 payments confirmed through; 15:00 mitigated, watchowner assigned, AAR due Monday 10:00 with the PSP gap as fix item #1 (their change-notification feed now monitored, not just their status page).

Make it durable: drills, laminated cards, and the volunteer bench

• Rotate the IC in drills. The person who always commands is a key-person dependency with a pager. Every quarterly drill gets a different commander; that's how the second and third ICs are born before they're needed.
• Print the card. This page's two checklists fit one laminated sheet or a pinned channel message. At 3 a.m. nobody wants to skim a 4,000-word doc; the card is the doc.
• Pre-agree the spend cap. The IC's money decision is only fast if the cap was set on a calm day. Put the number in the escalation policy and revisit it in the annual ops budget.
• Log every command decision. The registry below is the paste-in tracker — one row per decision keeps the postmortem honest about when things were decided, not just what happened.

Keep the log machine-readable so the postmortem imports it directly:

id,time_utc,role,holder,decision,reason,next_review
1,14:05,IC,mo,"declared sev-1; self-assigned command","clear head; two prior drills",2026-09-30-aar
2,14:06,comms,tom,"first stakeholder update by 14:15","silence reads as absent",2026-09-30-aar
3,14:12,mitigation,ana,"rollback 13:40 candidate first","mitigate before diagnose",2026-09-30-aar
4,14:30,IC,mo,"decision point 15:00 manual-invoicing","deadline forces honesty",2026-09-30-aar
5,14:46,IC,mo,"vendor sev-1 ticket + hold-traffic banner","known vendor window",2026-09-30-aar

One CSV per incident, six lines, imported by the postmortem. The teams that look preternaturally calm during fires aren't calmer people — they've simply decided, on a quiet Tuesday, who speaks, who decides, and who types, so the loud Tuesday is just execution.