Slack Incident Management: What Works and What Breaks

What's in this post

• The four things Slack genuinely does better than dedicated tooling
• Five ways Slack breaks, and roughly what size of team hits each one
• A Slack incident workflow you can set up this afternoon
• The specific signals that mean it is time to add a pager
• FAQ

Every engineering team discovers incident management the same way. Something breaks, someone posts about it in #engineering, four people reply, one of them fixes it, and nobody writes anything down. Six months later there is a channel called #incidents, a pinned message nobody reads, and a shared belief that the process is under control.

It usually is, right up until the night it isn't.

The honest position on Slack is not that it is bad at incidents. It is very good at most of an incident. It is catastrophically bad at exactly one part, and unfortunately that part is the beginning.

What actually works in Slack

Start with the credit, because there is a lot of it and most "you need a real tool" posts skip straight past it.

The room is already open. The single biggest cost in an incident is the first five minutes of coordination, and Slack removes almost all of it. Everyone is already logged in, already has notifications configured, already knows where #incidents is. No tool you buy will beat a room people are already standing in. This is the whole argument for ChatOps, and it is a good argument.

Threads are a genuinely good incident structure. One message for the incident, one thread underneath it for the work. Investigation stays in the thread, the channel stays scannable, and anyone joining late can read the thread top to bottom and be caught up in ninety seconds. Very few purpose-built tools have improved on this.

Context is one paste away. The graph, the log line, the deploy diff, the screenshot of the dashboard. Getting evidence in front of other humans fast is what Slack is for, and during an incident it matters more than almost anything else.

Decisions get made where they get recorded. When the incident commander says "we're rolling back", that sentence exists, timestamped, in the same place as the evidence that led to it. That is a genuinely nice property, and it is why the post-incident review of a Slack-run incident is often easier than one run in a tool where the conversation happened somewhere else.

So: coordination, context, decisions, recall. Four out of five. Here is the fifth.

Where Slack breaks, by team size

Slack does not fail all at once. It fails in a fairly predictable order, and the order tracks team size more than it tracks sophistication. The thresholds below are our read from working with teams at each stage rather than a research finding, so treat them as a rough map, not a law.

Break 1: nobody is guaranteed to be awake (any team with an out-of-hours expectation)

This is the one that matters and it arrives on day one, not at some future headcount.

Slack is a notification system for people who are looking at Slack. Do Not Disturb, which every engineer with a functioning relationship to their own sleep has switched on, blocks notifications by design. Slack does give senders an escape hatch: on a direct message, a sender can override someone's paused notifications once per day, and you can add specific people to a VIP list. That is a human deciding to interrupt another human. It is not an automated alert reaching an on-call phone, and it is certainly not an alert from your monitoring stack reaching whoever is on call this week.

Which means the 03:00 question is not "did the alert fire". It is "did the one person who could have fixed this happen to be holding their phone". That is not a process. That is a coin flip with a pager-shaped hole in it, and it is the reason a dedicated Slack incident response layer exists at all: something has to turn an alert into a phone call, a second phone call, and then somebody else's phone call.

Break 2: no acknowledgement, so no accountability (roughly 5 to 10 engineers)

In Slack, the closest thing to acknowledging an incident is a 👀 emoji, and the closest thing to ownership is whoever typed first. Both are conventions, not states. Nothing in Slack knows whether an incident has been picked up, so nothing can act when it hasn't.

The failure mode is not dramatic. It is the incident everyone assumed someone else had taken, sitting in the channel for twenty minutes with three eyes emoji on it. You find out at the retro, when you try to reconstruct when work actually started and discover you cannot.

You also cannot measure anything. MTTA requires a recorded acknowledgement. Without one, your MTTR number is really "time from when someone remembered to say something to time from when someone remembered to say it was over", which is not a metric, it is a vibe.

Break 3: alert volume eats the channel (roughly 10 to 25 engineers)

Somewhere around the point where you have real monitoring on real services, the alert firehose arrives. Every check, every environment, every flapping threshold, all of it into one channel because that was easy to set up.

Two weeks later, nobody reads that channel. Not "reads it less". Does not read it. Alert fatigue is not a soft cultural problem, it is the mechanical result of a channel where 95% of messages require no action, and the fix is filtering rather than willpower. You can get a long way inside Slack here: routing by severity into separate channels and muting the low-priority ones outside business hours is a genuinely effective pattern, and we wrote up how to filter Slack alerts by severity and time as a step-by-step.

That buys you real time. It does not solve break 1 or break 2, because a quieter channel is still a channel.

Break 4: the record disappears (roughly 25 to 50 engineers, or your first compliance question)

On a free Slack workspace, you can view and search only the last 90 days of messages and files, and you can install at most 10 third-party or custom apps. If your incident history lives in Slack and your plan is free, your incident history has a shelf life shorter than a quarter.

Paid plans fix the retention part. They do not fix the shape of the problem, which is that a Slack channel is a stream, not a record. Ask "how many SEV1s did we have last quarter, and what was the median time to resolve", and in Slack the answer involves a person, a search box and an afternoon. Ask it during an ISO 27001/SOC-2 audit or a customer security review and the afternoon becomes a problem.

Break 5: nobody owns the incident (roughly 50 engineers and up, or your first multi-team incident)

Past a certain size, the incident that hurts is the one spanning three teams. Now you need someone to be the incident commander, someone to talk to customers, and someone to actually fix it, and those need to be three different people with three different jobs.

Slack has no concept of a role. It has people who are typing. In a five-person team that is fine, because everyone can see everyone. In a twenty-person incident it produces the specific chaos where four engineers debug the same thing in parallel, nobody updates the status page, and the CEO finds out from a customer.

A battle-tested Slack incident workflow

If you are staying in Slack for now, which is a completely reasonable decision for a small team, do not stay in it accidentally. This is the version that holds up.

1. Three channels, not one.

• #alerts-critical: wakes people. Only pages that genuinely need a human now.
• #alerts-low: everything else. Muted outside business hours, reviewed on a weekday morning.
• #incidents: humans only. No bots. This is where incidents are declared and run.

The split is the whole thing. If bot noise and human coordination share a channel, the humans lose.

2. Declare in a fixed format. One message in #incidents, always the same shape:

🔴 SEV2 · Checkout API returning 502s for ~15% of requests
Started: 14:32 UTC
IC: @niko
Comms: @peer
Status: investigating

Boring is the point. A fixed format means anyone scrolling the channel can triage in two seconds, and it means you can find things later.

3. Everything else goes in the thread. Investigation, theories, dead ends, the graph screenshots, all of it. The channel holds declarations and status changes only. Resist the urge to post "update:" in the channel; edit the parent message instead and let the thread carry the narrative.

4. Name an IC out loud, even for a one-person incident. Especially for a one-person incident, because that is the one that quietly becomes a four-person incident at 15:10 with nobody in charge. Naming it in the declaration message costs one line.

5. Close it explicitly. Edit the parent message to Status: resolved, post the end time, link the post-mortem doc if the severity warrants one. An incident that just stops being talked about was never really closed, and it will not be countable later.

6. Every Friday, read #alerts-low with a delete finger. Any alert that fired more than twice and required action zero times gets tuned or deleted that day. This is the single highest-leverage twenty minutes in the whole workflow, and it is the one everybody skips.

That workflow will carry a team of five to fifteen engineers a surprisingly long way. Be clear-eyed about what it still doesn't do: it does not wake anyone up, it does not escalate, and it does not count.

When to add dedicated tooling

Not "when you get big". When one of these becomes true:

• An incident was missed or badly delayed because nobody saw the alert. One is enough. This is the signal, and everything else on this list is a nicety by comparison.
• You cannot answer "who is on call on Saturday" without asking someone. If the rotation lives in a pinned message or a shared calendar that someone maintains by hand, it is already out of date and you will discover this on a Saturday.
• Someone external asks for incident numbers. An auditor, an enterprise prospect's security questionnaire, a customer with an SLA. The first time you have to reconstruct a quarter from Slack search, you have already paid for the tool.
• An incident spanned three teams and nobody was in charge. Roles need to be assignable before you need them assigned.
• You are muting #alerts-critical. If the channel that is supposed to wake people has been muted by people, the system has inverted and you are running on luck.

The good news is that adding tooling is not the same as leaving Slack, and anyone who tells you it is has something to sell you. The pattern that works is Slack as the room, a dedicated layer as the pager and the record: monitoring fires into the tool, the tool decides who is on call and escalates by push, SMS and phone call until someone acknowledges, and then it opens a channel in Slack where the humans do the actual work. The incident war room still happens in Slack. It just gets opened by something that does not sleep.

That is the shape of our own Slack integration, and it is also the shape of most of our competitors' Slack integrations, which is a reasonable sign that it is the right shape rather than a clever idea.

Where All Quiet earns the recommendation specifically: pricing is public and flat at $4.99 per user per month on Standard, with unlimited users, integrations and incidents and no seat minimum, which matters a lot when the team debating this is eight engineers and the incumbent quote arrived with an enterprise tier attached. Where it does not: if you already own a tool that reliably wakes people up, none of the above is a reason to switch, and we would rather you fixed your alert hygiene than bought anything.