Incident War-Room Communication Workflow

Run incident communication on separate channels for work, decisions, and stakeholder updates, with a scribe recording the timeline as it happens.

beginner~15 minincidentcommunicationsre

Objective

Keep an incident's working signal-to-noise high by separating execution chatter from decisions and stakeholder communication, with an authoritative timeline.

Environment

Dedicated channels: war room (voice or chat), decision log, stakeholder bridge
A scribe role assignable from the on-call pool
A status page for external communication

Steps

1. Open the room with roles

At incident start, open the war room and assign the three roles aloud: commander, scribe, and communications lead, stating each by name.

Expected state: The first three messages in the room are role assignments, not diagnostic guesses.

2. Keep the work channel signal-only

Enforce war-room discipline: observations and commands only, no speculation threads; side investigations move to their own threads and return with results.

Expected state: The work channel reads as a timeline of facts and actions, searchable afterward.

3. Log decisions with rationale

The scribe records every decision (rollback, failover, silence) with time, decider, and one-line rationale in the decision log channel.

Expected state: The decision log reconstructs the incident without archaeology.

4. Update stakeholders on a metronome

The communications lead posts stakeholder updates on a fixed cadence with impact, current action, and next update time, even when nothing changed.

Expected state: Stakeholders never need to enter the war room to know the state.

5. Close the room into the record

On stand-down, freeze the timeline, decision log, and channel transcripts into the incident record, then close the channels.

Expected state: The complete communication record is attached to the postmortem.

Expected outcome

Incidents with high-signal work channels, auditable decision logs, and stakeholders informed on cadence, producing a timeline the postmortem can actually use.

Verification

The incident record contains the timestamped decision log and transcripts; stakeholders confirm they never had to interrupt the war room for status.

Noise is the enemy inside the war room

A war room where everyone speculates simultaneously produces heat and no timeline. Separating work, decisions, and stakeholder updates into distinct channels with named roles keeps the signal high and the record complete.

#war-room-INC-2955
14:02 [cmdr]  roles: cmdr=ana, scribe=bo, comms=chi
14:03 [obs]   err rate 12% on /checkout, since 14:01Z
14:04 [cmdr]  hypothesis: v1.8.3 cache stampede -> TEST
14:06 [obs]   redis conn errors 400% up     [evidence]
14:07 [cmdr]  DECISION: flag cache_revalidate=off (ana)
14:09 [obs]   err 12% -> 0.4%   recovery

#decisions
14:07 flag off (cmdr ana): stampede suspected, 1-line change
14:11 keep flag off until redis patch (cmdr ana)

#stakeholders (every 15m)
14:05 / 14:20 / 14:35: impact, action, next update time

The scribe writes history while it happens

Reconstructing an incident from memory produces a fiction: what people think they decided and when. A scribe logging each decision with rationale in real time gives the postmortem an authoritative record and gives the commander freedom to think forward instead of remembering backward.

Metronome updates drain the stakeholder interruptions

Every well-meaning status question asked in the war room is an interruption to someone doing recovery work. A fixed-cadence update — including next update time even when nothing changed — satisfies the stakeholders’s real need and keeps them out of the room.