how to communicate during a SEV1 without chaos
Describes how to run communications during a SEV1 without chaos: one incident commander, one updates channel, 15-minute status cadence, and a redirect for side questions. Use when setting up incident comms norms or when live incidents turn noisy. Does not cover technical debugging.
TL;DR
One incident commander talks, one channel carries updates, and status posts go out every 15 minutes whether or not there is news. Chaos in a SEV1 is a communication problem, not a technical one. The fix is boring: roles, a single source of truth, and a cadence, all decided before the incident starts.
Error / query
how to communicate during a SEV1 without chaosThe incident is real, and now forty people are typing over each other while the responders cant think. You need comms discipline, fast.
Use this skill when
- a SEV1 is declared and communication is already chaotic
- youre setting up incident communication norms before the next one
- too many people talk over each other in the incident channel
- execs are DMing engineers directly during an outage
Not for this skill when
- you need technical debugging steps (a different skill)
- you need a postmortem template (that comes after)
- you need the paging and escalation policy (see the escalation skill)
Steps
1. Declare one incident commander and one comms channel
Post the war-room header immediately. A single named commander and one channel where everyone listens.
cat > /tmp/incident-kickoff.txt <<'EOF'
SEV1 declared: [short description]
Incident commander: [name]
Comms channel: #incident-2026-10-04
Status updates every 15 min from the commander
Debugging happens in the linked thread, not this channel
EOF
cat /tmp/incident-kickoff.txtExpected: a single named commander and one channel. Everyone knows where to listen and who is in charge.
2. Move debugging out of the main channel
Debugging chatter buries status updates. The main channel carries commander updates only; all troubleshooting goes in a thread.
cat > /tmp/channel-rules.txt <<'EOF'
Channel rules for this incident:
1. Commander posts status updates here, every 15 min.
2. All debugging goes in the thread. No troubleshooting in the main channel.
3. Questions for responders go in the thread; the commander answers on the next update.
EOF
cat /tmp/channel-rules.txtExpected: the rules posted and visible. The main channel stays readable at a glance for the next hour.
3. Start the 15-minute update timer
No news is still news. A timer keeps the cadence honest when the commander is deep in the incident.
(while true; do sleep 900; echo "TIME TO POST A STATUS UPDATE"; done) &
echo "update timer started, pid $!"Expected: a background loop that nudges the commander every 15 minutes. "Still investigating, no change" is a valid update.
4. Deflect side conversations with one redirect line
Protect responders from drive-by questions. Paste this wherever side threads start.
cat > /tmp/redirect.txt <<'EOF'
All updates are in #incident-2026-10-04 from the commander. Please don't DM engineers during the incident; ask in the channel and the commander will answer on the next update.
EOF
cat /tmp/redirect.txtExpected: a paste-ready redirect message that keeps responders focused and questions flowing to one place.
Variant phrasings
how to run incident communications
Same fix: commander plus single channel plus cadence is the whole method. Everything else is detail.
sev1 communication best practices
Same fix: the practices that matter are named roles, one source of truth, and timed updates. Decided in advance, not invented mid-incident.
how to stop people from pinging engineers during an outage
Same fix: the redirect message in step 4, enforced by the commander. It works because it gives people somewhere to go instead of just saying no.
Why it happens
During a SEV1, information is the scarcest resource, so people invent their own channels to get it: DMs, side threads, hallway conversations. Each new channel makes the real picture harder to assemble. Centralizing communication feels slower but resolves incidents faster, because the commander stops spending half their time answering the same question five times.
Edge cases and pitfalls
- The commander is also the best debugger: split the roles. One person cant command and debug at the same time.
- Remote team across time zones: the commander hands off explicitly, with a written summary, never by just going quiet.
- Execs demanding private briefings: give them a read-only digest from the commander, not direct access to responders.
- A 200-person incident channel: lock posting to the commander and active responders; everyone else reads.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_AgXEPJtnEWiyjJ-9WRCu-A
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.