What is a Webhook Retry?
A webhook retry is an attempt to send a webhook message that has already failed. Webhook retries are a best practice when designing webhook systems to achieve high reliability and deliverability of event notifications: without them, a few seconds of receiver downtime means events are silently lost.
What triggers a retry
A delivery counts as failed when the webhook endpoint returns a non-2xx status code, or when it does not respond before the sender's timeout. Both cases are treated the same way because the sender cannot tell the difference between an endpoint that is down and one that is merely slow. This is also why receivers should acknowledge deliveries quickly and process them asynchronously: an endpoint that does heavy work before responding will time out, get retried, and end up processing the same event twice.
Retry schedules
In most webhook systems, retries are implemented with exponential backoff: quick retries first to recover from transient blips, then progressively longer waits. For example, Svix's automatic retry schedule is:
- Immediately
- 5 seconds
- 5 minutes
- 30 minutes
- 2 hours
- 5 hours
- 10 hours
- 10 hours (in addition to the previous)
This gives customers more than a day to fix a potentially broken endpoint while not bottlenecking the system with failing messages. Senders that exhaust the schedule shouldn't discard the message: parking it in a dead letter queue preserves it for inspection and replay once the receiver is healthy again.
What retries mean for receivers
Retries are the reason duplicate deliveries are normal in webhook systems. If your endpoint processes a delivery successfully but the acknowledgment is lost on the network, the sender retries and you receive the same event twice. Receivers should treat every delivery as potentially repeated and deduplicate using the message ID; our guide on idempotency and deduplication covers the standard patterns.
Retries can also arrive out of order. A failed message that succeeds on its third attempt may land after newer events that were delivered on their first, so receivers should rely on timestamps in the payload rather than arrival order.
Manual retries and replay
Automatic schedules handle transient failure, but sometimes a receiver is broken for longer than any schedule tolerates. Good webhook systems also support manually retrying or replaying messages after the fact, so a receiver that was down for a day can recover the events it missed. Svix offers manual retries in the dashboard UI as well as through the API, alongside bulk replay of failed messages.
For the sender-side design tradeoffs, see our retry best practices guide and the deeper treatment in webhook retry strategies.