## 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

```text
how to communicate during a SEV1 without chaos
```

The 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.

```bash
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.txt
```

Expected: 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.

```bash
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.txt
```

Expected: 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.

```bash
(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.

```bash
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.txt
```

Expected: 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