Running an incident channel in Slack or Teams
Give each incident its own Slack or Teams channel, opened at declaration and named so it can be found later. Put the roles and a pinned summary at the top, keep the channel for facts and decisions, move side talk to threads, update on a set rhythm, hand over in the open, and close the channel with a final summary.
One incident, one channel
When an incident is declared, work moves to one place. A dedicated channel in Slack or Teams gives the team a shared record, a place that people can join without reading unrelated chat, and a clean thing to review afterwards. The alternative, a running thread in a busy channel, buries the incident in the day’s other messages and makes the next person to arrive scroll for the story.
The tool matters less than the discipline. Slack and Teams both support channels, threads, pinned or featured messages and links to a call, though they differ in how channels are organised and archived. Pick one place for incidents, write the conventions down, and have the whole team use them. A workflow that is the same every time is one that people can follow at three in the morning.
Naming and opening
A channel name is a promise about how easy it will be to find later. Use a convention with three parts.
| Part | Purpose | Example, illustrative |
|---|---|---|
| Prefix | Makes every incident easy to list | inc |
| Date | Sorts them, and dates the record | 2026-10-01 |
| Description | Tells a newcomer what it is about | checkout-errors |
Together: inc-2026-10-01-checkout-errors. Keep the severity out of the name, because it can change, and put it in the
channel topic instead, along with a link to the summary. Open the channel at the moment of declaration, and invite the
commander, the on-call engineer and the owning team first. Others can join as needed.
Roles at the top
The first message says who is doing what. It saves the questions that would fill the next ten minutes.
- Commander. The person coordinating. The role is described in the incident commander in a small company.
- Fixer, or ops lead. The person investigating and changing systems.
- Communications. The person writing updates for customers and the company.
- Scribe. The person keeping the timeline, who can also be the communications person on a small incident.
Keep the list of people in the channel short. Responders speak; watchers, such as managers and support, read. It is fair to invite them, and it is fair to ask them to hold questions for the updates channel.
The pinned summary
One message, pinned and edited, does more than a stream of updates. Anyone joining late reads it and is up to date. It should have the same fields every time.
| Field | What to write |
|---|---|
| Status | Investigating, mitigating, monitoring or resolved |
| Impact | Who is affected and how, in plain words |
| Started | When it began, and when it was detected |
| Roles | Commander, fixer, communications, scribe |
| Current hypothesis | The leading idea, marked as unconfirmed if it is |
| Next update | The time the next summary will be posted |
| Links | Dashboards, ticket, call, runbook |
Edit the same message, do not post a new one, and stick to the rhythm the commander sets. A summary that is fresh at the time it says builds trust: people stop asking “any news?”.
A timeline that writes itself
The review needs to know what happened and when. The easiest way to have that is to keep it as you go. The scribe posts short, timed facts: “14:05 rolled back the release”, “14:12 error rate back to normal”. Mark decisions clearly, with a word such as “decision”, and say who made them. Keep hypotheses out of the timeline, or label them as hypotheses.
This is the record that feeds the review, whether written by people or drafted by a tool, as covered in AI-written postmortems. A timeline built from typed facts is far better material than a memory of what was said in a call.
Keeping noise out
An incident channel goes wrong in a predictable way: it fills with speculation, questions and reactions until the useful messages are lost. A few rules, agreed in advance and pinned as a short charter, prevent that.
- Facts and decisions here. Anything else goes in a thread.
- Questions to the commander, not to the room. If a stakeholder needs an answer, the updates channel is the place.
- No “any update?” The pinned summary is the update.
- Limit the bots. Alert bots and deploy bots can post to the channel, but pipe long output to a link.
- Be kind, be firm. The commander redirects off-topic messages early, without blame.
The rules belong to the team, not to the tool. Write them once, review them after each incident, and change them when they get in the way.
Side threads and calls
Some work needs its own space. Use threads for a sub-investigation, such as “the cache theory”, so the main channel stays readable. When talking is faster than typing, start a short call or video bridge and pin the link in the summary. The rule for calls is simple: whatever is decided on a call is typed into the channel, with the name of who decided it. A decision that exists only in a call does not exist for the people who were not on it, or for the review.
An example opening message
This is an illustrative first message, posted by the person who declares the incident:
Incident declared: checkout errors. Impact: some customers cannot pay. Commander: Sam. Fixer: Priya. Communications and scribe: Alex. Summary is pinned. Next update at 14:30. Side theories in threads, please. Updates for the wider company go in the updates channel.
It states the impact, names the four roles, points to the pinned summary, sets the next update, and states the rule about threads, all in a few lines. The next person to join needs nothing more to be useful.
Slack and Teams differences worth knowing
The habits above work in either tool, but the tools differ in ways that affect the design of your workflow.
- Where channels live. In Teams, a channel sits inside a team, so who can see it depends on the team’s membership unless it is a private or shared channel. In Slack, a channel is public or private in the workspace.
- Limits. One channel per incident means many channels over time. Both tools set limits on channels and members, so check the current limits before you rely on the pattern (for Teams, Microsoft’s limits and specifications page), and plan how you archive old ones.
- Pinning and editing. Both let you pin or feature a message and edit it. Test the steps your summary depends on.
- Closing. Archiving and locking work differently. Decide what “closed” means in your tool and write it in the charter.
Handoff and closing
When the commander changes, say so in the channel: who is leaving, who is taking over, and the current picture, ideally by updating the pinned summary at the same moment. The same applies when a fixer hands over to a colleague.
To close, follow a short routine:
- Post that the incident is resolved, and the time.
- Post a final summary: impact, timeline, cause if known, and the links.
- List the follow-ups, each with an owner and a date.
- Link the review meeting or document.
- Archive or lock the channel as your tool allows. Do not delete it.
Look at how the incident compared with the numbers you track, in MTTA vs MTTR, and add anything the channel taught you to the charter.
Frequently asked questions
Should every incident get its own channel?
Yes, for anything beyond a trivial fix. A separate channel keeps the facts together, lets people join and leave without scrolling through unrelated chat, and leaves a clean record for the review. Small incidents can use a thread in a shared channel if your team agrees a rule for when to open a new one.
How should we name an incident channel?
Use a fixed prefix, the date and a short plain description, for example an incident prefix, the date, then "checkout-errors". The prefix makes every incident easy to find, the date sorts them, and the description helps someone new to the channel. Keep severity in the topic, because it can change during the incident.
What belongs in the pinned summary?
The current status, the customer impact, the start time, the commander and other roles, the leading hypothesis, when the next update is due, and links to dashboards, the ticket and any call. It is one message that is edited as things change, so anyone joining late can read it in a minute.
How do we stop the channel filling with noise?
Agree a rule that the channel is for facts and decisions, use threads for side investigations, keep stakeholder questions in a separate updates channel, and let the summary answer "what is the status?". The commander enforces the rule kindly and early, before the habit forms.
When and how do we close the channel?
When the incident is resolved and the follow-ups have owners. Post a final summary with the timeline, the impact and the links to the review, then archive or lock the channel as your tool allows. Do not delete it: it is the record the review and later incidents will use.