How long do Sume webhooks retry? About three hours vs Stripe

Sume retries a terminal webhook up to 10 times, with a 30 second base that doubles and is capped at an hour, which adds up to a little over three hours before jitter. Stripe's page, read 2026-10-10, says it retries live-mode events for up to three days.

The difference changes how you recover. With Sume, a long outage on your side needs a plan, because deliveries stop and you must fetch the result or redeliver.

Neither policy is wrong; they are tuned for different events. A payment event may need to survive a weekend, while a run result can always be fetched again from its result URL.

The arithmetic

The Run webhooks page gives 10 attempts, a 10 second timeout on each, a backoff of 30 seconds times 2 to the power of attempt minus one with jitter, a maximum of an hour, and Retry-After honored. The waits between the ten attempts are 30, 60, 120, 240, 480, 960, 1920, 3600, and 3600 seconds, which sums to 11,010 seconds, or about 3 hours and 4 minutes, plus up to 10 seconds for each attempt.

Jitter moves each wait a little, and a Retry-After from your server can lengthen a wait, so treat three hours as a rough ceiling, not a promise.

Side by side

Stripe documents manual resends in the Dashboard for up to 15 days and through the CLI for up to 30 days after the event. It also says events can arrive more than once and out of order, so track event ids.

Sume has the same advice in different words: request_id equals the run id, which is the dedupe key. After delivery fails, the receipt's webhook_delivery.status shows failed or exhausted, and POST /v1/format-runs/{id}/webhook/redeliver, which needs formats:write, sends it again. It returns 409 webhook_not_configured or run_not_terminal when it cannot.

Both vendors say the same thing about receivers: verify the signature on the raw body, answer quickly with a 2xx, and do the slow work afterward. Stripe's page also advises against a replay tolerance of zero, since that disables the recency check.

What to do about the gap

Do not rely on webhooks alone for anything that matters. Run a reconciler that finds runs in your index with no terminal state and reads their receipts, and use redeliver when you want the event pushed again. The receipt carries webhook_delivery.status, with values not_armed, pending, retrying, delivered, failed, and exhausted, so the reconciler can focus on failed and exhausted.

Because a Sume result stays readable at its result URL, a missed webhook is an inconvenience, not a loss. The reconciler is what turns that into practice.

A deploy-safe handler

Return a non-2xx during a deploy and Sume will retry, so a rolling restart is safe as long as the window is shorter than about three hours. For longer maintenance, expect to redeliver afterward. Always verify the signature first and refuse to run when the secret is empty.