Slack Web API 3-second timeout and retry behavior

Maximum retries before discard

Slack’s Events API documents a retry ceiling of three retries after the initial delivery, for a maximum of four total attempts per event. The backoff schedule is approximately 1 second, 2 seconds, and 4 seconds. If the fourth attempt does not receive a 2xx response within the 3-second window, Slack discards the event. These figures reflect documented behavior through late 2023 and should be re-verified against current Slack documentation because platform limits can change.

Behavior on HTTP 429 during backoff

A 429 response is treated as a temporary failure, not a success. Slack will schedule another retry. If the response includes a valid Retry-After header, Slack waits for the specified interval before the next attempt. If the header is missing or malformed, Slack falls back to its standard exponential backoff sequence. Importantly, the 429 does not reset the retry counter; it consumes one of the three available retries. Each attempt, including the one that returned 429, must still be answered within 3 seconds or it counts as a timeout failure.

Verification steps

1. Confirm the current retry policy in the official Slack Events API documentation under event delivery and retry behavior.
2. Build a local test endpoint that returns 429 with a Retry-After: 2 header on the first call and 200 on subsequent calls. Log the X-Slack-Retry-Num and X-Slack-Retry-Reason headers Slack sends to correlate attempts.
3. Repeat the test without the Retry-After header to observe whether Slack reverts to the documented exponential backoff.
4. Add an artificial delay longer than 3 seconds to confirm that slow responses are counted as failures and trigger the next retry.

Assumptions and uncertainty

The retry count and backoff timings described here are based on Slack’s published documentation as of late 2023. Slack may adjust these values, and network intermediaries can consume part of the 3-second budget. Treat the numbers as a design baseline and verify them with a controlled endpoint before relying on them for production capacity planning.