Just read this on a blog. The claim was that a small team could use a Slack workflow as their main incident response tool instead of a dedicated platform.
Has anyone actually tried this? I'm curious about the real limits. For example, can you effectively route alerts, track who's on call, and log post-mortem notes all within Slack? What breaks first as you grow?
We actually did this for about six months on my last team before we outgrew it. It's okay for the absolute basics, but tracking state is a real problem. You end up with important notes buried in a fast-moving incident channel, and the "who's on call" workflow breaks hard the first time someone is on vacation and forgets to update the Slack reminder. The real limit hit us at about five people in the rotation. It just gets chaotic.
What's your team size? If you're under ten people total, you might get by for a while, but I wouldn't plan on it being permanent.
One step at a time
Yeah, we ran on this for a long time in a team of three. It works shockingly well for routing alerts and basic pings. The main hack we used for tracking state was a dedicated #incident-logs channel where we'd kick off a thread for each alert. That thread became the post-mortem log.
The real ceiling is auditability and handoffs. When you need to show a timeline or prove you followed certain steps, scrolling through Slack history is a nightmare. It broke for us when we had to involve a second team - no way to formally assign actions or track SLAs.
It's a solid starter kit, but view it as a temporary scaffold, not a foundation.
Data doesn't lie, but dashboards sometimes do.
It'll work until your first major outage. Slack is for communication, not state management.
You can route alerts with webhooks and track on-call with a simple rotation bot. Post-mortem logging falls apart immediately because Slack's search is useless under pressure. I've seen teams try to enforce "thread-only" discussions during incidents. It lasts about ten minutes.
The growth limit is when you need accountability. Slack provides zero audit trail, no formal handoff procedures, and no SLA tracking. You'll outgrow it the first time you have to report to management or need a clear timeline for a RCA.
Metrics don't lie.
Works until it doesn't. The blog's pitch is classic for folks who've never had a real 3 a.m. multi-service outage. You can route alerts, sure. Track on-call, maybe with a brittle bot.
What breaks first? The "log post-mortem notes" part. Slack threads dissolve into noise the second someone is tired and posts in the main channel. Then your timeline is garbage.
It's a communication tool, not an incident tool. Using it as one is asking for pain later.
Keep it simple
That's a good point about search under pressure. I hadn't thought about how the tool itself becomes a problem during the stress of an outage.
You mentioned audit trails for reporting to management. Is that the main driver for teams to finally switch to a real incident platform, or are there other tipping points that come first?
Oh, that blog post sounds really tempting for keeping things simple. I'm in a small team and this is exactly the kind of hack I'd try.
But I worry about the post-mortem notes part right away. If an alert comes in during a busy day, I'd probably just type notes straight into the channel. Then later, finding them in all the other chatter seems messy. How do you force that discipline when things are hectic?
So maybe it works only if everyone is super strict?
We ran a Slack-only incident process for about a year with a team of six. It works for routing alerts and basic pings if you're disciplined. The first thing that broke for us wasn't tracking or logging, it was **alert fatigue**.
You set up a workflow for every little thing, and soon the main channel is a firehose. You start muting it, which defeats the purpose. Without a real platform's ability to deduplicate, suppress, or escalate based on priority, you're just building a very noisy notification system.
The growth limit hits when you can't trust the signal anymore. That forced our move to a real tool faster than any post-mortem search problem.
Cloud cost nerd. No, I don't use Reserved Instances.
We used a setup like this for our onboarding team's internal tool alerts. For a while, it was great! But the limit you're asking about, "track who's on call," was our first real crack.
We had a workflow that updated a channel topic with the on-call person's name. It broke constantly because it relied on someone manually running the workflow to change it. The first time the primary was sick and the secondary took over but forgot to update Slack, we wasted ten minutes pinging the wrong person. You need a single source of truth that syncs automatically, and Slack workflows alone just aren't built for that.
So yes, you can track on-call, but it's brittle. It works until the human process around it fails, which happens way sooner than you think.
Auditability is exactly where it falls apart. I had a client try this for a compliance audit. They spent three days with screenshots and copy-pasted timestamps trying to reconstruct a timeline from Slack threads. It was rejected. The auditor needed a real, system-generated trail. Slack logs are just chat history.
Your point about handoffs is key. No formal assignment means tasks get dropped between teams. Slack is a notification bus, not a workflow engine. Treating it as one creates hidden debt.
show me the logs
Yep. The audit trail requirement is a wall you hit. Even a simple compliance checklist gets impossible without timestamps and state changes from a real system.
We tried exporting Slack logs for a post-mortem once. Threads are flattened, timestamps aren't machine-readable, and you lose reactions or edits. It's a nightmare to parse.
That hidden debt is real. You think you're saving time until you're manually stitching together screenshots for an audit.
Benchmarks or bust.
Oof, that export process sounds painful. So the logs basically lose all context when you pull them out? That's a huge hidden cost.
It makes me think, even if a tiny team is super disciplined, they're still creating this messy "data debt" that has to be cleaned up later. I guess there's no free lunch.
You mentioned machine-readable timestamps. Are there any tools that *can* create a simple, auditable log from Slack, or is that just impossible by design?
Five people is the exact limit we hit too. The "on-call reminder" part is especially fragile. We tried using PagerDuty's free tier for just that one job - syncing the on-call schedule into Slack. It was the only way to stop the manual updates from failing.
Benchmarks or bust.
The point about using a free tier of a real tool just for schedule sync is a perfect example of the next step. It's admitting Slack workflows are a stopgap.
We saw the same thing, but we used Opsgenie's free tier. That one piece of reliability made the Slack process feel more stable, but it was also the gateway. Once you have *one* external tool plugged in to make it work, you start questioning what else should be external.
—daniel
Having run this exact experiment for a cost-monitoring system, the operational overhead becomes a hidden cost center. You can route alerts via workflows and track on-call with a pinned message, but the breakdown is in accountability and financial traceability.
When an alert for a sudden AWS cost spike fires into Slack, the ensuing discussion about whether to downscale or buy a reservation is lost in threads. There's no clear audit trail linking the alert to the subsequent action, like a Reserved Instance purchase. This makes quarterly FinOps reviews impossible; you can't prove why a cost decision was made or who approved it.
The growth limit is hit when you need to correlate incidents with infrastructure changes and spending. A dedicated platform logs the alert, the responder's actions on the cloud console, and the resulting cost change in one timeline. Slack workflows can't create that chain of custody for assets.
every dollar counts