Sume webhook retries last 270 to 370 seconds: when to poll

Sume tries a job webhook up to 10 times in total, with a fixed 30 second gap by default and a 10 second timeout per attempt. If your endpoint fails instantly, that is 9 gaps, or 270 seconds, before the last attempt. If every attempt runs to the full timeout, the window is 10 x 10 + 9 x 30, or 370 seconds. A receiver that is down for longer than that has to recover jobs by polling or by Redeliver.

The arithmetic

These figures come from the Webhooks docs: up to 10 attempts total, a fixed delay between attempts (30 seconds by default, not exponential backoff), and 10 seconds per attempt.

What this means for a deploy

A rolling restart that takes under four and a half minutes is covered by retries, as long as you answer 2xx only after the event is stored. A longer outage means the job reached its real terminal state but the delivery is marked failed.

• Keep status_url polling available for jobs that never get a callback.
• After an outage, POST /v1/jobs/{job_id}/webhook/redeliver re-sends the real terminal event with a fresh signature. It does not use one of the automatic 10 attempts.
• Use job_id as your idempotency key, because retries and Redeliver can send the same event again.

A caveat on the spacing

Thirty seconds is described as the default spacing, so treat 270 and 370 as the numbers for a default setup and read the Webhooks page again if your workspace differs.