Slack's documentation says an app may post no more than about one message per second per channel, with short bursts tolerated. Beyond that you get HTTP 429 responses with a Retry-After header. Batch findings into one message and honour the wait, or alerts get dropped.
What the documentation states
The Slack rate limit page says apps may post no more than one message per second per channel, whether the call is a message API call or an incoming webhook. Short bursts above that are tolerated, but sustained overuse leads to rate limiting. When a limit is hit, the API returns HTTP 429 Too Many Requests with a Retry-After header giving the seconds to wait. Limits for one method or workspace do not block other methods or workspaces.
Treat those numbers as the current documented behaviour and check the page when you build, since limits can change.
Why security automation hits this
A first scan of a large estate can produce hundreds of findings at once. If each finding posts a message, the tool tries hundreds of posts in a few seconds. Most would fail or be delayed.
How to design around it
- Batch. Group findings by repository or team and post one summary message with a count and the top items.
- Prefer threads. Post one parent message and add details as replies, and keep the number of parents low.
- Queue outgoing messages in your own system with a worker that sends at a steady pace per channel.
- Respect 429. Read Retry-After, wait that many seconds, and retry the same request. Do not retry in a tight loop.
- Cap the burst. If a scan creates more than a set number of items, send a single "many new findings" message with a link to the filtered list.
- Keep a durable record elsewhere. The ticket system, not the channel, is the source of truth, so a dropped message loses a nudge and not a finding.
What to do when a channel is flooded anyway
Stop and look at the design. A channel that receives dozens of messages a minute is already unreadable. The rate limit is a symptom. The answer is fewer, better alerts, as covered in what a chat alert should contain.
Quick check
What should my code do on an HTTP 429 from the chat API?
Wait for the number of seconds in the Retry-After header, then retry the same request. Avoid immediate retries.
Is the chat channel a safe place to be the only record of an alert?
No. Messages can be dropped or deleted. Keep the finding and its status in a ticket or findings system.
Safeguard supports policies and gates that decide which findings need attention, which helps keep alert volume down. A free scan is at gold.safeguard.sh/scan.
Sources
- Slack developer docs, Rate limits
Last reviewed: 19 October 2026.
