A Runbook for Your Slack Incident Channel

Gathering context manually - switching between Datadog, GitHub, PagerDuty, Slack history, and runbook documents - takes 20-30 minutes. That's time the incident commander doesn't have. What follows is the playbook most teams don't write down until after the third bad incident.

The four roles your channel needs in the first three minutes

The incident commander is the single person responsible for coordinating the response - making decisions, assigning tasks, and keeping the team focused. They are not necessarily the most technical person on the call. Their job is leadership: who's doing what, what we know, when you'll update stakeholders, when to escalate. That means they should not be debugging the database.

The IC holds the 30,000-foot view so technical responders can focus entirely on resolution. The fastest way to lose that view is to put them in charge of writing the status update prose.

The four roles, named at the top of the channel before anything else:

A basic three-step process that runs every time - create the #incident-YYYY channel, page on-call in channel, update the status page when resolved - is worth more than elaborate documentation that gets skipped under pressure.

Name the channel consistently. #inc-2026-09-17-payments-timeout is infinitely better than #payments-issue-urgent. Two concurrent incidents in the same #incidents channel is chaos - people talking past each other, updates for incident A mixed with questions about incident B. This is usually the first sign you need dedicated channels per incident.

The status update cadence that actually holds

Status updates are the job that most incidents do worst. Updates every 15-30 minutes during active incidents, even if there's nothing new to report - silence is worse than "still investigating, next update at 14:30."

The structure of every update is the same three lines:

• What we know: current state of the system and visible symptoms
• What we're doing: the active hypothesis or fix being attempted
• When the next update lands: a clock time, not "soon"

You can set a workflow that sends a Slack reminder to the incident commander every 30 minutes for SEV1 incidents: "Time for a status update. Use /inc update to post to the channel and status page simultaneously." That removes one more thing the IC has to track mentally during a crisis.

The non-obvious problem: the IC owns stakeholder communication and ensures internal Slack updates on a defined cadence for SEV1. But every minute they spend drafting prose is a minute they're not coordinating the fix. The comms lead role exists to solve this - they draft, the IC approves in under 30 seconds. Set a timer: every 20 minutes, a stakeholder update goes out, no exceptions. The comms lead drafts, the IC approves in 30 seconds.

What the scribe must capture - and when

ICs who don't capture what happened during an incident create the postmortem problem - 90 minutes of reconstruction from failing memory. Assign a dedicated scribe role, or use tooling that captures the timeline automatically.

The scribe captures four things in real time, timestamped to the minute:

• Decisions made and who made them (not just the outcome)
• Hypotheses tested and what ruled them out
• Actions taken - deploys, rollbacks, config changes, restarts
• Severity changes and the reason stated at the time

Every message, file share, and action in Slack creates an automatic timeline of events. This chronological record is invaluable for understanding incident progression, tracking decision points, identifying when specific actions were taken, and creating accurate post-mortem reports. But Slack's history is not a scribe - it doesn't distinguish a decision from noise. That's the scribe's job: filter and timestamp, in the channel, as it happens.

From resolution to postmortem first draft

The immediate problem is mitigated, service is restored even if the underlying cause isn't fully understood, the status page goes back to operational, and the incident commander stands down the response team. At that point the channel still has one job left: the postmortem seed.

Before the channel goes quiet, pin three things:

1. The scribe's timestamped decision log
2. The final status update (this is the customer-facing summary)
3. A postmortem ticket with owners and a due date - within 24-72 hours of resolution, while memory is fresh but emotions have cooled

Postmortems take a week to assemble because the timeline is scattered across four or more tools. If the scribe kept a live log, that number drops sharply. The postmortem template itself should be standing - not written under pressure. Five sections: timeline, customer impact, root cause, contributing factors, action items with owners and dates. If your postmortems aren't producing action items that actually get done, you're doing them wrong.

One genuinely non-obvious thing most incident runbooks miss: conversations about what severity an incident is can very quickly consume the entire call and don't change the fact that there is an incident ongoing. Severity should not be discussed during the incident call - treat it as the highest severity you think it could be, and downgrade in the postmortem. Severity debates are a comms problem masquerading as a technical one. The runbook should say this explicitly.

Incident channel runbook: common questions

What's the right update cadence for a Slack incident channel?

Every 15-30 minutes for SEV1, every 30-60 minutes for SEV2. Post an update even when nothing has changed - "still investigating, next update at 15:00" is better than silence. Stakeholders will flood the channel with questions if they don't hear from you, and that noise slows the response.

Who should own the incident channel in Slack?

The incident commander pins to coordination and owns decisions. They should not draft status updates or write the timeline. Assign a comms lead to draft stakeholder updates and a scribe to log the timeline. For small teams, one person can cover both - but the IC stays out of the prose queue.

When does a dedicated incident channel make sense versus a shared #incidents channel?

Use a dedicated per-incident channel any time two or more incidents might run concurrently, or when you anticipate more than four or five active participants. A shared #incidents channel works for teams under around 20 people with low incident frequency; beyond that, message interleaving creates real coordination failures.

How do you write a postmortem when the timeline is scattered across Slack?

Assign a live scribe during the incident and have them post timestamped entries directly into the incident channel. After resolution, that thread becomes the first draft. If no scribe was assigned, pull the channel export, sort by time, and strip messages to decisions and actions only - expect to spend 60-90 minutes on reconstruction.

What belongs in the channel topic during an active incident?

Current severity, incident commander's name, last-update time, and a link to the runbook or status page. Update the topic on every severity change and at resolution. Engineers joining mid-incident should be able to orient themselves from the topic alone without scrolling history.