The first 12 minutes of a production incident are almost never spent fixing anything. Most SRE teams see median P1 MTTR between 45-60 minutes, with roughly 12 minutes spent just assembling the team and gathering context - and another 12 at the end on coordination wrap-up. The coordination tax lives in those bookends, not in the diagnosis.
That is the thing worth fixing. Not the runbook. Not the on-call rotation. The opening scramble where nobody knows who declared the incident, which channel to use, or who is writing the stakeholder update while the engineer tries to actually fix the thing.
This is a playbook for that scramble.
Why one channel per incident is non-negotiable
Two concurrent incidents in the same #incidents channel is chaos - people talking past each other, updates for incident A getting mixed with questions about incident B. That is usually the first sign a team needs dedicated channels per incident.
The naming convention matters more than teams admit.
Use a consistent pattern - something like #inc-severity1-payments-down or #inc-20260731-api-latency - so urgency and scope are legible before anyone opens the channel.
When the channel opens, context should arrive automatically: incident details, severity, service information, and runbook links posted to the channel. Stakeholders get visibility through a centralized announcement channel so they are not cluttering the response space. If you are doing that by hand, you will skip it at 2 AM.
The three roles - and why Comms Lead is the one teams forget
At minimum you need an Incident Commander, a Communications Lead, and the subject-matter responders for the affected systems, with roles assigned as early as possible.
Most small teams assign the first two and skip the third. That is why major incidents pull in five, ten, sometimes twenty people, and without structured orchestration the channel becomes a status meeting - incident commanders spend their time answering the same three questions repeatedly, and actual technical diagnosis slows to a crawl.
The Comms Lead's only job during active response is to write updates outward - to #incidents-updates or directly to leadership - so the IC and Responder are not interrupted.
Keeping all operational chatter in the incident channel lets engineers focus on mitigation while stakeholders get curated updates elsewhere.
A concrete cadence that actually holds: post a structured update every 15 minutes from declaration to resolution. Not a free-form message - a templated one: