The first fifteen minutes of an incident

The first fifteen minutes decide most incidents. Name one person in charge, stop the damage before explaining it, say what you know and nothing more, and write everything down as it happens.

Work down the page while it’s happening. Tick each step as it’s done and the time goes beside it; fill in who holds which role and what you’ve learned, and copy a summary into your team’s chat whenever someone asks where things stand.

The first fifteen minutes

Minute 0. Say it out loud in one channel: "I think we have an incident: what users see." Open an incident channel or thread.
An incident nobody has declared is several people fixing different things in private.
Minute 1. Name the incident commander. If nobody else takes it, you have it.
Without one person deciding, nothing gets decided.
Minute 2. Name a scribe. Start the timeline: every action, with the time.
Memory after an incident is wrong; the timeline is the record.
Minutes 3 to 5. Set the severity from what users cannot do, not from what is broken inside.
Severity decides who gets woken and how often people hear from you.
Minutes 5 to 10. Stop the damage first: roll back, fail over, disable the feature, stop the job, or switch on maintenance mode. Explain later.
A running fault keeps adding harm while you diagnose it.
By minute 10. Send the first update. Promise the time of the next update, not a time for the fix.
People decide what to do from updates; silence makes them guess.
Minutes 10 to 15. Open the matching runbook and follow it out loud.
Runbooks hold the steps nobody remembers at 3 a.m.
At the cadence your severity sets. An update, even if it says nothing has changed: every 30 minutes at SEV1, hourly at SEV2, at the start and the end at SEV3. Keep the promised time.
A missed update reads as "they have lost control".

Who holds which role

On a small team one person holds several roles. Say out loud which ones, so nobody assumes someone else has them.

Incident commander

Decides, coordinates, sets severity, calls rollback or failover, owns the updates. Doesn't fix things while commanding.

Scribe

Writes the timeline: every step, time, finding and decision, and who made it.

Communications

The commander, until the incident is big enough to need a second person. Nothing unconfirmed goes outside.

Business owner

Makes the business calls: accept lost orders, take the site down, fail over.

Everyone else is a responder: investigate and fix, saying each step out loud, and don't change production without telling the commander.

Severity, from what users cannot do

A starting point to adapt, not a standard. Raise severity freely and lower it carefully: starting high and stepping down costs a few minutes; starting low and discovering it was the top level costs the incident.

SEV1. Users can't buy or pay, or data is being damaged or exposed. Everyone needed, now, any hour; updates every 30 minutes; the business owner told at once. SEV2. A revenue path is hard to complete, or a major feature is down with a workaround. On-call now, others in working hours; updates hourly. SEV3. A minor feature is down, or staff are affected and customers aren't. Working hours; one update when it starts and one when it ends. SEV4. Nothing yet: a latent fault or lost redundancy, like one node of three down. A ticket with a date.

The first five questions

Ask them out loud, in this order, and put the answers in the timeline.

What can users not do, and since when?
What changed? A deploy, a config push, a cache flush, a scheduled job, a partner's status page, a traffic spike.
Is it getting worse? Growing errors, queues or damaged records mean stopping the damage comes first.
Can we stop the damage without understanding it? Roll back, disable, fail over, stop the job, maintenance mode.
Who else needs to know right now? The business owner, support, a partner.

The shape of an update

What happened.
What people are seeing.
What we know.
What we do not know yet.
What we are doing.
When the next update comes.

Confirmed and suspected never share a sentence: "Checkout is failing for card payments. We think it started with this morning's deploy and are checking." Promise the next update, not a fix time, and keep it.