Production is down. Someone posts in #engineering: "checkout is 5xx." Three engineers jump into the same service. Two others start a separate thread. The person who actually owns the payment gateway is asleep in Amsterdam. Six minutes in, no one has told support, and the CEO is reading about the outage on a customer's tweet.
Every engineering team starts incident management the same way. Someone posts in #engineering: "prod is down." Three people reply, two investigate the same thing, and the one person who actually knows the affected service is asleep. This works at 10 engineers - everyone knows who owns what. By 25 engineers, you're running incidents across five different Slack channels with no idea who's actually on-call. The playbook below does not assume you have PagerDuty or FireHydrant. It assumes you have Slack, a willing team, and a recurring problem.
Set up the channel before you need to think
A dedicated incident channel is the non-negotiable first step.
Create a dedicated Slack channel for each incident at declaration time. The naming convention should include date and descriptor - for example, #inc-2026-06-01-checkout-5xx.
That name does real work: it is searchable after the fact, it signals severity at a glance, and it prevents two incidents from bleeding into the same thread.
Incident details, severity, service information, and runbook links should be posted to the channel automatically at creation. If you are not using an automation tool yet, a pinned Slack message with a structured template achieves 80% of the same result. The template should include: declared severity, impacted services, IC name, comms lead name, runbook URL, and time of next update.
The runbook URL must be stable and included in the alert text - discoverability at 3 AM cannot depend on knowing where to look. If your runbooks live in a Notion page three clicks deep, move them. GitOps-style markdown in the same repository as the service being monitored is the most maintainable pattern: runbooks are co-located with the code they describe, reviewed in the same pull request process, and version-controlled with the same rigor.
Assign three roles in the first five minutes
In the middle of an incident, ambiguity compounds stress. Two people assume someone else is updating stakeholders. Five engineers jump into debugging the same service. Important decisions get delayed because no one is sure who owns them. The fix is not a new tool. It is three explicit role assignments posted in the channel within the first five minutes of declaration.
| Role | What they do | What they do NOT do |
|---|---|---|
| Incident Commander (IC) | Owns the call, assigns tasks, decides severity | Diagnoses or writes code |
| Comms Lead | Writes stakeholder updates, liaises with support | Joins the technical thread |
| Scribe | Logs every action and decision with a timestamp | Filters or edits - just records |
Organizations using the IC model consistently save 15-30 minutes per incident. The IC should maintain a timestamped incident timeline tracking: detection time, acknowledgment time, mitigation time, and resolution time.
The scribe is the role teams drop first under pressure. It feels like overhead when everyone is stressed and wants to fix the thing. But the scribe maintains a timestamped record of every action taken, decision made, and update sent throughout the incident - this record becomes the foundation of the blameless postmortem. Without a scribe, teams reconstruct timelines from fragmented Slack histories and often get them wrong.
This is exactly where an AI teammate earns its keep. The scribe role requires no judgment - it requires attentiveness and accuracy. Beagle can watch the channel, maintain the running timeline in a thread, and draft the handoff summary when the shift changes, freeing every human in the channel to focus on the problem.
Beagle in action#inc-2026-09-09-payment-timeout, 2:47amRun two channels, not one
Incident communication involves two separate challenges that are often conflated. Track 1 - internal response: getting the right engineers aware and mobilized immediately; speed is everything, every minute of delay is direct cost. Track 2 - stakeholder communication: keeping management, affected departments, and end users informed throughout; this requires different content, different channels, and different timing. Most organizations focus on Track 1 and neglect Track 2 - or handle both through the same channel, which creates noise for responders and leaves stakeholders in the dark.
The practical structure is simple:
#inc-YYYY-MM-DD-descriptor- the working channel. Responders only. Raw technical output, hypotheses, commands, results.#incidentsor#status-internal- the announcement channel. Plain language. Impact and ETA, not root cause.
When stakeholders have a reliable place to get updates, they stop pinging on-call engineers. When on-call engineers stop being pinged, they can focus. That focus is directly reflected in your MTTR.
Keep the update cadence rigid
Update cadence is not about more communication - it is about the right communication at the right frequency. Updating too rarely breeds speculation. Updating too frequently breeds noise and can itself signal a lack of control. The goal is a predictable rhythm that stakeholders can rely on.
The standard cadences:
- SEV-1 / P1: every 20-30 minutes, even if there is nothing new
- SEV-2 / P2: every hour
- SEV-3 and below: upon resolution only
The single most effective communication practice - confirmed across incident.io, PagerDuty, and Rootly research - is: always state when the next update will arrive. Every update ends with: "Next update at 03:15 or sooner if status changes." That one line stops the "any update?" messages that pull engineers out of diagnosis.
Acknowledge the issue, describe what is affected and its scope, state that investigation is underway, and commit to a time for the next update. Do not include a root cause hypothesis or an ETA you cannot confirm. Speed matters more than completeness in the first message.
Close the channel cleanly, before the postmortem
Incidents do not end at resolution. They end when the postmortem is written and the action items have owners. On average, it takes about 4 days to complete and share the postmortem document - because once all the information is at your fingertips, it still takes someone with organizational and technical context to synthesize it into what went well and opportunities to improve.
Hold a postmortem within 24 to 72 hours after resolution. This timing keeps facts fresh while giving responders enough time to recover and prepare. A good postmortem covers: incident summary, impact, timeline, what went well, what failed, root causes or contributing factors, action items, owners, deadlines, and documentation plan.
The scribe thread Beagle maintained throughout the incident becomes the first draft of the timeline section. Comms lead takes the stakeholder updates and turns them into the customer-facing summary. IC owns the action items. Nobody reconstructs anything from memory.
Incident channel Slack playbook: common questions
What's the right naming convention for a Slack incident channel?
Use date plus a short service descriptor: #inc-YYYY-MM-DD-service-symptom. This format is searchable, sorts chronologically in your channel list, and tells a new responder at a glance which system is affected. Avoid generic names like #outage - they are not searchable and cannot hold more than one incident.
How often should you post stakeholder updates during an incident?
For SEV-1 outages, post every 20-30 minutes regardless of whether there is new information. For SEV-2, every hour. Each update must close with the time of the next one. The cadence matters more than the content - silence breeds speculation and triggers status-request pings that pull engineers out of diagnosis.
Who should be in the incident channel?
Responders only. Stakeholders belong in a separate announcement or status channel where they can follow without adding noise. When stakeholders have a reliable place to find updates, they stop pinging on-call engineers, and that is what directly improves MTTR.
Do you need a scribe role for every incident?
Yes, but it does not have to be a human. For anything above SEV-3, a timestamped log of every action and decision is the difference between a postmortem that writes itself and one that takes four days of reconstruction from fragmented memory. An AI teammate watching the channel can carry this job without taking a seat away from the engineers doing the diagnosis.
When should you write the postmortem?
Within 24-72 hours of resolution. Waiting longer means details fade and action items drift. The Atlassian guidance caps it at five business days, but the sweet spot is closer to 48 hours - enough time for responders to rest, not enough time for the context to evaporate.