Webhook retry: fixed delay vs exponential backoff, with numbers

A fixed-delay retry waits the same time between attempts; exponential backoff doubles the wait each time, so it keeps trying for longer with the same attempt count. Sume uses both: job webhooks retry on a fixed delay of 30 seconds by default, and run webhooks use exponential backoff with jitter capped at one hour. Both stop after 10 attempts.

The difference matters most during an outage of your endpoint: the job schedule gives up in minutes, the run schedule in hours. The arithmetic below is derived from the documented formula and ignores jitter, Retry-After and the 10-second timeout each attempt can use.

What is the difference between fixed and exponential?

Fixed delay is simple and predictable, and it hits a struggling endpoint at a steady rate. Exponential backoff spaces attempts out so a down endpoint gets less traffic and more time to recover. Sume's Webhooks page says its job webhooks use "a fixed delay between attempts (30s by default), not exponential backoff".

How long does each Sume schedule keep trying?

Ten attempts leave nine gaps. For run webhooks the documented gap is min(max(30s x 2^(attempt-1) with jitter, Retry-After), 1h); counting attempts from 1, the gaps before the one-hour cap are 30, 60, 120, 240, 480, 960 and 1,920 seconds, and the last two are capped at 3,600.

What happens when the window runs out?

Nothing happens to the work. Ten refused attempts leave a failed delivery and a job or run that still reached its real terminal state. Job docs say to keep status_url polling available for events that never arrive; for runs, fetch the receipt from result_url. Redeliver replays the real terminal event and does not consume one of the automatic 10.

Which schedule should my receiver plan for?

If your endpoint can be down for more than a few minutes, treat a job webhook as best effort and poll the job as your backup. For run webhooks, the longer window covers most short deploy gaps, and an endpoint that returns 429 or 503 with Retry-After can stretch a gap up to the one-hour cap. On both surfaces, return 2xx quickly after durably storing the event, and dedupe: job_id for jobs, request_id for runs.