Retry failed webhook deliveries on a schedule that spans multiple days, with exponential backoff and random jitter, treat any response other than 2xx as a failure, and send the same webhook id on every attempt. That is the guidance in the Standard Webhooks specification.
Definition
A retry schedule is the set of delays between delivery attempts. Exponential backoff means each delay is longer than the last. Jitter adds a random amount to each delay so that many failed deliveries do not all retry at the same instant.
Why jitter matters
Picture a customer endpoint that goes down for ten minutes. Thousands of your queued events fail together. If every one retries after exactly one minute, then two, they arrive as synchronized waves. A receiver that has just recovered gets flattened again, which keeps it down. Jitter spreads attempts out so a recovering service sees a ramp, not a wall.
This is also a defense for you. Retry traffic from your own workers competes with fresh events. A schedule without randomness creates predictable spikes in your own queue.
What the spec says
According to the spec: retry on a schedule that spans multiple days, with exponential backoff and random jitter; use webhook-id as an idempotency key, for example by storing ids to block duplicates; treat any response other than 2xx as a failure; and treat 410 Gone as a signal to disable the endpoint. A timeout of roughly 15 to 30 seconds is recommended per attempt.
An example schedule
This is an illustration, not a prescribed schedule.
| Attempt | Base delay | With jitter |
|---|---|---|
| 1 | Immediate | None |
| 2 | About 30 seconds | Add a random share of the base |
| 3 | About 5 minutes | Same |
| 4 | About 30 minutes | Same |
| 5 | About 2 hours | Same |
| 6 and later | Several hours, widening | Same, until the end of your window |
Pick your own numbers, publish them, and apply them consistently.
Steps
- Choose a retry window and a maximum number of attempts and document them for customers.
- Implement backoff with jitter in the delivery worker, not in each integration.
- Keep webhook-id constant across attempts so receivers can deduplicate. See duplicate event handling.
- Cap concurrency per destination so one slow endpoint cannot use up your worker pool.
- Pause retries when an endpoint is clearly down and resume with a ramp.
- At the end of the window, mark the delivery failed, surface it in a dashboard, and follow your disable policy.
Per destination limits
One customer's broken endpoint should not delay events for everyone else. Use separate queues or concurrency caps per destination. That isolation is a reliability control and a security one, since hostile URLs can otherwise be used to stall delivery for others.
Where Safeguard fits
Safeguard's dependency scanning covers the queueing and HTTP client libraries behind your delivery workers, and its policy gates help keep reviews in your release flow. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Why add randomness to a delay I can already compute?
Without it, many failed events retry in sync and can overwhelm a recovering receiver. Jitter spreads the load.
Should retries use a new event id?
No. Keep the same id so receivers can detect and ignore duplicates.
Sources
Last reviewed: 19 October 2026.
