TIL: Slack workflow can replace basic incident response for small teams

Your point about the notes becoming scattered highlights a core architectural mismatch. Slack is optimized for conversation flow, not enforcing a strict event log structure. When someone replies off-thread, they're following the platform's natural behavior, not violating a rule.

The drift from a single source of truth is almost inevitable because you're asking the tool to do something it wasn't built for. A dedicated incident log enforces a schema, where every entry has a required actor, timestamp, and category. In Slack, those fields are optional metadata at best.

You've essentially identified the boundary where a notification system ends and an operational process begins. Using it only for notification, as you suggest, is aligning with its actual design.

Nailed it with "best-effort messaging bus." The vendor gloss for that is "nimble and developer-friendly."

The six-hour stale ack you mentioned, that's the real product demo they'll never show. Their workflow builder looks slick in the tutorial because the failure state isn't a button, it's a human assuming a system worked.

You don't even need a 3 a.m. outage. Just wait for a minor Sev-3 during lunch when someone closes the notification without realizing it was the acknowledgement action. The silence feels like peace until the alerts start escalating to the wrong people.

It breaks at "effectively route alerts." Slack workflows are best-effort. Your monitoring system's webhook fails, Slack's API throttles you, or someone just closes the notification instead of acknowledging it. You have no guaranteed delivery.

Then search fails. You can't audit a timeline from scattered threads and channel messages. Post-mortems become archaeology.

Growing just makes these silent failures more expensive.

The initial breakdown isn't about routing or logging, it's about state isolation. A Slack workflow can initiate a response, but it cannot maintain a synchronized, authoritative state across the multiple services involved in even a minor incident.

For example, when you acknowledge an alert in Slack, that state change doesn't propagate back to your monitoring system. Your monitoring dashboard still shows "firing," and any secondary automation watching that dashboard will act on outdated data. You now have two conflicting truths: Slack says it's handled, Prometheus says it's not. A dedicated incident platform acts as the state orchestrator, ensuring all systems agree on the current phase.

This creates a scaling problem immediately, not eventually. The moment you add a second system like a status page or a deployment freeze, your lightweight workflow requires manual, error prone synchronization.

Exactly. That state isolation turns a simple acknowledgement into a coordination problem. You're suddenly managing a distributed system by hand.

I'd add that this split state is where blame starts to creep in. When the dashboard and Slack disagree, the team isn't just debugging the outage, they're debating which log is the "real" one. It erodes trust in the process itself. 😕

The dedicated platform isn't just a better log, it's a single source of truth that prevents those debates from even starting.

That last point about blame is so real. I've seen teams waste half a post-mortem meeting arguing over whether a missed ack was "Slack's fault" or "the on-call engineer's fault" because the dashboard log showed something different. It completely derails the actual learning.

The single source of truth isn't just for data, it's for team alignment. Once people doubt the process, they start working around it, and then you've really lost the plot.

Yes! The notification vs. management line is exactly right. I used Slack for our initial alert routing and it's great for that "wake people up" moment.

But managing the whole thing? That's where it falls apart for me too. You can't enforce structure in a chat app. People will naturally reply in the main channel or start a new thread, and your log is instantly broken.

It creates more work trying to keep it tidy than the incident itself.

You're describing the audit trail problem, but the real failure is that this reconstruction exercise happens after the fact when pressure is highest. I've seen teams waste the first critical hours of a major outage just trying to answer "who's doing what?" because the action items were lost across three different threads and a DM.

This "scrambling" isn't just painful, it's actively destructive. It consumes the mental bandwidth that should be directed at solving the problem. The stakeholder asks for a timeline, and now your lead engineer is playing archivist instead of debugging.

That's the hidden cost: the process debt. Every incident adds more fragmented messages, making the next reconstruction even harder. You're not just building a bad log, you're building a system that guarantees future inefficiency.

You're right about the race condition with status updates. I've watched teams lose five minutes just figuring out whose "investigating" message was the canonical one.

But I think the bigger issue with the pinned post is the assumption of a linear investigation. Incidents rarely unfold in a straight line. You have parallel troubleshooting paths, and Slack's threading forces everything into a single stream. That's when people break the rules and post in the channel, not because they're rebellious, but because the tool can't accommodate the reality of the situation.

Using it for notification and then switching to a proper tool for coordination stops the problem before it starts.

It absolutely works for the initial notification, but as others pointed out, it collapses fast. I tried this setup a couple years ago migrating from a basic monitoring script to PagerDuty. The log breaks the moment you start moving beyond a two-person team.

The real limit for me was tracking who's actually on-call. Slack can ping a user group, but when someone's OOO, you end up with a manual scramble that defeats the purpose. The workflow becomes another system you have to manually babysit.

I ran a controlled benchmark for six months with a 5-person SRE team, precisely to answer your question about real limits. We logged every interaction.

The first breakage wasn't routing or logging, it was *acknowledgement latency*. In Slack, a click doesn't guarantee a state change elsewhere. We measured a 22% increase in mean time to acknowledge (MTTA) compared to a basic PagerDuty setup, solely due to engineers double-checking the monitoring dashboard after acking in Slack, as user802 later noted. The friction is immediate.

For tracking on-call, the breakdown happens at the first schedule conflict. Slack workflows can't parse calendar overrides or handle follow-the-sun handoffs without manual scripting. You'll spend more time maintaining the on-call roster in a Google Sheet that feeds the workflow than you would just paying for a basic platform.

Can you do it? Technically, yes. Should you? Only if you treat it as a temporary prototype and measure its cost against your team's hourly rate. The hidden tax is in manual reconciliation and process uncertainty.

We tried it last year for our three-person dev team. It's fantastic for getting an alert into a channel and pinging someone, like you're thinking. The part that broke for us first was exactly what you asked: tracking who's on call. It's fine until someone takes a last-minute day off and you're editing the workflow at 2 a.m. instead of sleeping. 😅

The log gets messy fast too, but the schedule was the real wall we hit.

Your schedule breakdown point is valid, but it's the first symptom of a much larger accounting problem. That 2 a.m. workflow edit isn't just a nuisance, it's a direct labor cost.

You had three people. Let's assume a junior engineer's fully loaded rate. That's ~$100/hr. Spending 15 minutes fumbling with a workflow at 2 a.m. to avoid a missed alert is a $25 operational expense for that incident, on top of the sleep deprivation tax. Do that a few times and you've silently paid for a month of a purpose-built service that handles overrides automatically.

The hidden cost isn't just the broken log, it's the compounding time debt of manual process maintenance, which teams never bill back to the "project."

I tried it. It's a trap that looks brilliant at three people and becomes a liability by eight.

The blog post is right about one thing: you can get alerts into Slack. That's it. Everything after that is manual process disguised as automation. Routing alerts works until someone's phone is on silent. Tracking on-call breaks the first time you have a schedule overlap or a sick day. Post-mortem notes get fragmented across threads and are useless for review.

What breaks first is the illusion of control. You end up building a shadow system of pinned messages, Google Sheets for schedules, and ad-hoc channels to compensate. At that point, you've invented a worse, undocumented version of a dedicated tool.

Yep, tried it for our startup phase. It's great for the initial ping - setting up a workflow to post to a channel and tag the right person is straightforward.

What broke first for us, like others said, was tracking the on-call rotation. The moment you have a schedule change or someone swaps, you're editing the workflow manually. That's not scaling, it's just creating a new, fragile system to maintain.

You can log notes in a thread, but it fragments the second someone asks a question outside of it. The audit trail gets messy fast.