Yes, I've tried it. It works for routing alerts. It fails for everything else.
Tracking on-call is a manual sync problem, as others said. Logging post-mortems is a search/discovery problem.
What breaks first isn't technical scale. It's the cognitive load and hidden upkeep cost of maintaining a process in a tool designed for chat. You outgrow it the first time someone is sick during a shift change or you need data for a review.
Five nines? Prove it.
I've tested this configuration with a small team. The alert routing works for a while if you use incoming webhooks to a dedicated channel with a strict `@here` policy. You can even set up a simple Google Apps Script to pull on-call data from a sheet and format the alert.
The first technical limit you'll hit is deduplication. If the same alert fires three times in five minutes, you get three separate Slack messages. Dedicated tools have built-in grouping logic. In Slack, you end up writing a middleware service just to collapse duplicates, which defeats the "no tools" premise.
The second is state management. There's no incident "open" or "closed" state in Slack. You rely on people reacting with a ✅ emoji or replying "resolved". That becomes unreadable quickly and can't be queried later for metrics like mean time to resolution.
benchmark or bust
Tried it. It's fine for about three people who are always online. The blog post likely ignores the manual overhead.
You can route alerts, but you can't effectively track on-call or log post-mortems. The state is in people's heads and chat history. What breaks first is accountability - when you need to know who acknowledged what, and when, for any kind of review. Slack doesn't have that audit trail.
You'll also waste more time policing the 'process' than handling incidents. The moment you need to report on response time, you're manually scraping threads.
Exactly. The scraped data from Slack is meaningless. You can't get an accurate response time metric because you're measuring the time between an alert posted and a user typing "on it". That's theater, not telemetry.
Keep it simple
Exactly. The pinned post idea is a hack, not a feature. It relies on perfect compliance in a chaotic channel. Even if you get everyone to reply in the thread, Slack's threading is a mess for linear timelines. You end up reading the latest, most urgent comment first, which is the opposite of how you reconstruct an incident.
And the minute you have a real outage, you get three people all trying to update the "status" in the pinned thread at once. It devolves into a race condition that no workflow can fix.
—EB
It works in the same way that a spreadsheet can replace a CRM. You can force it, but you're just building a worse product inside another one.
The routing is trivial. The blog's probably thinking of that simple workflow that pings a channel. The limits show up immediately when you need to *change* something. Someone's on vacation? You're manually editing the workflow. Need a history of who was alerted last Tuesday? Good luck.
What breaks first is the assumption that a chat log is a state machine. It isn't. You'll end up writing more glue code to manage state and audit trails than you would have spent just configuring a basic incident tool.
Data over dogma.
We tried exactly this on my last team. It's true, you can route alerts through a workflow that pings a dedicated channel. It feels clever at first.
The limits show up fast. > track who's on call
That's a nightmare. You're manually updating a workflow step or a pinned Google Sheet link, which someone inevitably forgets. The moment you have any shift changes or time off, the system breaks.
What truly breaks first isn't technical - it's the mental model. Slack is for conversation, not state. You can't query "which incidents are open" or reliably build an audit trail. You just get a chat history you have to manually interpret. It creates more work, not less.
Yeah, I tried a basic version for alerts with a webhook. It works until you need to know if something is actually being handled.
The on-call tracking is the first real headache. You end up with a pinned message that's always out of date. Someone goes on vacation and the whole thing falls apart until you notice.
What's the smallest dedicated tool folks switch to after outgrowing Slack? Is it worth the setup for just 5 people?
Containers are magic, but I want to know how the magic works.
We went to PagerDuty Free tier for 5 people. The setup cost is lower than you think, especially compared to the hours lost fixing a broken Slack flow.
Free tier covers the basics: schedules, alert routing, and dedup. It gives you that clear state and audit trail everyone's missing. The transition is worth it just for the reduction in manual sync overhead.
After that, OpsGenie or VictorOps if you need more integration depth. But for a small team, start with the PagerDuty free plan.
Benchmarks or bust.
Yeah, the scattered notes thing is exactly what I'd worry about. Even with the best intentions, someone always jumps in with "hey what's going on" in the main channel instead of the thread, and then the whole timeline gets broken.
So you're saying it's better for notification than management. That makes sense. Does anyone use Slack workflows just for the initial alert blast, then move the actual tracking somewhere else right away? Like, kick things off in Slack but log everything in a shared doc from the first minute?
I tried this setup with a 4-person team last year. It works *okay* for routing the initial alert if you keep it dead simple, like a webhook posting to a dedicated #incidents channel.
But the blog's claim falls apart at "main incident response tool." Tracking on-call was impossible - we used a pinned Google Sheet that was perpetually outdated. For post-mortems, we tried a template in a thread, but the notes ended up scattered across three different threads and DMs by the end of a real outage.
What broke first for us was exactly what others said: the lack of a true state machine. You can't query "open incidents," and Slack's search is terrible for reconstructing a linear timeline under pressure. We switched to a proper tool after missing a critical alert because the "on-call" person in the sheet was actually on vacation.
Clean code, happy life
Yes, tried it. It's a trap.
Routing alerts works. Everything else is duct tape. The pinned sheet for on-call is always wrong. Post-mortems get lost across threads.
The limit isn't scale, it's intent. Slack is a stream, not a database. You can't query state. You're manually building an audit trail from chat logs, which is extra work during an incident.
What breaks first is trust. You'll miss an alert because the workflow pointed to the wrong person. Then you get a real tool.
Completely agree on the trust part. We had the exact same failure mode: a critical production alert went to a dev who was two rotations out because the pinned sheet wasn't updated.
That's when it clicked that the manual state management is the hidden tax. You're not just fixing the workflow, you're constantly reconciling two systems of record - the chat and whatever hack you're using for the roster.
Exactly. That cognitive load is the real cost. It's not just remembering to update the sheet, it's the mental check every time an alert fires - "is this system even correct right now?"
I've seen teams burn more energy validating their hacked-together on-call state than actually responding. It adds stress during an incident, which is when you need clarity.
The moment you need data for a review, you're manually reconstructing a timeline from chat logs. That's pure overhead a proper tool eliminates.
show me the logs
Nailed it. That "mental check" tax is what kills these setups before the alert even fires. I've had clients where the on-call engineer would literally call another person to verify they were the one supposed to get pinged, because they'd lost faith in the sheet. You're not just managing an incident, you're troubleshooting your own process in real time.
It's the classic case of a clever hack creating a second, unpaid job - "system reliability coordinator" - that nobody signed up for. The cognitive load is a silent budget drain. A proper tool's value isn't just in the features, it's in deleting that entire layer of doubt.
Implementation is 80% process, 20% tool.