Incident Communication & Escalation

## One incident, one place The single organising rule of incident communication is that at any moment there is exactly one authoritative location for the response. Creating a channel per incident, named so it is unmistakable, achieves this cheaply. Everything follows from it. **Self-service catch-up.** People join an incident continuously — an escalated specialist, a support lead, someone waking up. If the state of the response lives in a channel, they read it. If it does not, every arrival costs a responder an interruption to explain, and interruptions land hardest on precisely the people whose attention is scarcest. "Read the channel, then ask what is unclear" is only possible if the channel is complete. **Separation from routine traffic.** In the team's normal channel the incident is interleaved with standup chatter, code review pings and someone's unrelated question. Nobody can reconstruct it later, and newcomers cannot tell which of the last two hundred messages are the outage. **A boundary for the record.** The channel's contents are the raw material for the postmortem timeline. A per-incident channel gives that record clean start and end boundaries with nothing to filter out. **No side channels.** The corrosive failure is direct messages. Two people solve part of the problem in a DM, the channel never learns it, someone else repeats the work, and the timeline is missing the piece that mattered. The same applies to a vendor's support portal or another team's channel: mirror the outcome back into the incident channel even when the conversation had to happen elsewhere. ## The bridge trade-off A voice or video bridge is not a competitor to the channel; it does something the channel cannot. Voice is far faster for high-bandwidth exchange — "what does that graph do at 14:02?", "try it now", "no, stop" — and screen sharing conveys in ten seconds what would take five minutes to describe. For a fast-moving incident with several people, a bridge is usually the right call. Its cost is that it is invisible and unsearchable. Nothing said on a call exists for someone joining later, for a stakeholder update, or for the postmortem. A bridge-only incident regularly produces a postmortem where nobody can say who decided to fail over or what they knew at the time. The resolution is a simple discipline: the bridge is where you think, the channel is where you record. Any observation, any action taken against production, and any decision gets typed into the channel as it happens, usually by whoever is coordinating rather than by the person with their hands on the system. One line is enough — "decision: failing over to the secondary, accepting up to 30 seconds of lost writes". Post the bridge link in the channel too, so joiners find it without asking. ## Working channel versus status channel As an incident grows, the responder channel attracts an audience: managers, account teams, curious colleagues. Their questions are legitimate but they are interruptions. The standard split is two surfaces — the working channel for responders, and a separate stakeholder or status channel that carries only the periodic updates. Say clearly in the working channel where updates will be posted so people can subscribe to the right one, and be prepared to move a stakeholder conversation out of the working channel politely and immediately. ## Practical mechanics A few things make this work rather than merely sound good. Create the channel automatically at declaration so nobody spends the first three minutes on naming, and use a consistent scheme so the channel is findable later. Pin the essentials at the top: current impact statement, incident commander, bridge link, and the location of any shared document. Post the current status periodically into the channel itself so a joiner sees it without scrolling. Have deployment, rollback and configuration systems post their events into the channel automatically, so the highest-value factual entries appear without anyone typing. And archive rather than delete when it is over, because that scrollback is the evidence the postmortem is built on. ## The decision behind the question Asked plainly: is the extra ceremony of a dedicated channel worth it for a small incident? For a five-minute blip handled by one person, it can be overhead. The reason mature teams do it anyway is that you cannot tell which incidents are small until afterwards, and you cannot retroactively create a record of the first twenty minutes of the one that turned out to be large. Creating the channel is cheap and reversible; discovering at hour two that the first hour was conducted in three separate direct-message threads is neither.