Slack error rate_limited: Posting messages too quickly

The message-posting variant of throttling. chat.postMessage documents rate_limited (with the underscore) as "Application has posted too many messages, read the Rate Limit documentation for more information" — distinct from the generic ratelimited string that any method can return. Message posting has a special condition on top of the tier system: Slack's rate-limit documentation states it will "generally allow an app to post 1 message per second to a specific channel," with short bursts over that tolerated but sustained overruns throttled. Incoming webhooks carry the same 1-per-second guidance.

The per-channel scoping is the useful detail: an app can message many channels concurrently, but hammering one channel — an alert storm into #ops, a migration replaying history into a single room — trips this quickly. The remedy is per-channel pacing: a queue per destination that releases at 1 message per second, coalescing bursts into digests where the product allows.

Handle the response like any 429: honor Retry-After, then resume paced. If a feature fundamentally needs higher sustained throughput into one channel, no parameter unlocks it — redesign toward fewer, richer messages (Block Kit sections, threads, or files) instead of more messages.

HTTP/1.1 429 Too Many Requests
Retry-After: 30

{"ok": false, "error": "rate_limited"}

Assume every destination channel tolerates one message per second and design notification volume accordingly — summarize, thread, and batch. Alerting products should include storm suppression (N alerts in a minute become one digest) as a feature, not an afterthought. The posting rule sits alongside the tier table in Slack rate limits.