If you were on Slack's free plan on 1 October 2026, you may have found yourself blocked from sending messages for over six hours. Slack says the cause was a third-party app integration looping out of control, not anything you did.
Started
12:39 UTC
Duration
Lasted 6h 23m
Source
IsDown
Next time
Slack is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Messaging
What happened?
Slack logged one incident on this day, starting at 12:39 UTC and running for 6h 23m before resolution, affecting the Messaging component. The first update said Slack was aware that some free plan customers were hitting message-sending limit blocks in an "unusual spike pattern" and was investigating why. By 12:56 Slack had narrowed it down: a third-party app was stuck in a loop that had triggered billions of messages, pushing free plan users over their messaging thresholds and causing the block. At 13:58 Slack gave more detail, attributing the loop to a feature toggle ramp-up that caused an app integration to repeatedly post messages, and said it was working on remediation for affected workspaces. A potential fix was identified by 14:31, and Slack said it was working to get that out to users. The final update, at 18:52, said deployment of the fix was underway and Slack was monitoring the environment as it rolled out, but no update after that closed the loop with a formal resolution notice. Five updates were published in total over the six hours, all addressing the same root issue rather than separate incidents. No user reports were filed during this window on this record. Slack's own account is the only source here, there is no independent post-mortem to check it against. The fault sits entirely with how Slack enforces its free plan limits when a third-party integration misbehaves, not with anything on your side.
Learning
This incident is a good example of a failure that lives entirely inside the provider's own enforcement logic, not in the network path between you and Slack. A third-party app looping out of control triggered a volume-based block that Slack applied automatically, which means your own endpoint checks, your API calls, your webhook listeners, all of that could look completely normal while your free plan workspace was still locked out of sending messages. Watching your own integration from your side would not have shown you this, because the block was happening on Slack's infrastructure in response to someone else's app, not yours. Over the past 90 days Slack has logged 8 incidents with a median duration of 4 hours 33 minutes, and UptimeRobot's own 30 day data shows 4 resolved incidents with a median duration of 7h 40m, so outages of this length are not unusual for this provider. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
