Slack incoming webhook 1/sec: when 100 Sume jobs finish together

Slack incoming webhooks allow about 1 message per second. When 100 Sume jobs finish at once, store each webhook, then post to Slack from a paced queue.

4 min readSume
All posts

Slack documents incoming webhooks at 1 message per second, with short bursts above that allowed. A Sume bulk run of 100 items can finish within a short window, so do not post to Slack from each Sume webhook handler. Store the event, return a 2xx, and let a paced queue do the Slack posts.

Slack numbers are from its rate-limits page, read 2026-10-01. Sume behavior is from Bulk runs, Webhooks and Run webhooks.

What does Slack say happens when you exceed it?

The page lists incoming webhooks at "1 per second" and says short bursts above one are allowed. Exceeding the limit returns HTTP 429 Too Many Requests with a Retry-After header giving the number of seconds until you can retry. Honour it.

Why do 100 Sume jobs hit that limit?

A bulk run takes 1-100 items and a required concurrency from 1 to 16, so up to 16 child runs complete in parallel and finishes cluster. Each child run can register its own terminal webhook, since the queue itself has no webhook. If every handler posts to Slack inline, 100 near-simultaneous finishes means far more than one message per second.

Where the pressure comes from and what absorbs it, read 2026-10-01.
PieceFactWhat to do
Bulk run size1-100 itemsExpect up to 100 events
Bulk concurrencyRequired integer 1-16Finishes arrive in clusters
Sume deliveryUp to 10 attempts totalReturn 2xx fast after storing
DuplicatesDedupe run webhooks on request_id (equals run_id); job webhooks on job_idSkip an id you already posted
Slack1 per second, bursts allowedPost from a paced queue

How should the handler be split?

Two stages. Stage one is the Sume webhook handler: verify, write the event keyed by its id (request_id for a run webhook, job_id for a job webhook), return 2xx. Stage two is a worker that drains stored events at or below one message per second and, on a Slack 429, waits for Retry-After. Sume's run-webhook sender also honours a Retry-After from your endpoint on 429 or 503, but storing the event and returning 2xx quickly is the documented path. A queue product can host stage two; see Cloudflare Workers Queues for video webhooks.

Should I send one summary message instead?

Often, yes. A single message such as "98 of 100 done, 2 failed" needs one Slack request, and you can post it when the bulk run's status_url shows every item is terminal. Note that the docs say completed means every item is terminal, not that all succeeded, so branch on counts.failed. For the run itself, see Format bulk runs: 100 renders.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume