Webhook Retries and Failed Deliveries

When your receiving system is down, the webhook isn't lost at once, but what happens next depends on the sender. Some apps retry on their own. Others log the failure and leave the rest to you.

Why deliveries fail

GitHub gives a plain example: if your server is down or takes longer than 10 seconds to respond, GitHub will record the delivery as a failure¹.

A 503 response is one sign of this. MDN lists common causes as a server that is down for maintenance or that is overloaded². The page on response codes covers the others.

Two different approaches

Sources: Stripe and GitHub documentation, checked 2026-11-14³¹.

Exponential backoff means the waits between attempts grow longer. Stripe says you can view when the next retry will occur in the Event deliveries tab³.

Resending by hand

On GitHub, you can manually redeliver failed deliveries¹. It also describes a script that runs on a schedule, checks for failures since its last run, and redelivers them¹.

Stripe offers two ways to resend. The Dashboard has a Resend button on each event, which works for up to 15 days after the event was created. The command line tool works for up to 30 days³.

Note that a manual resend on Stripe doesn't cancel the automatic retries. Stripe's page says so, even when the resend returns a 2xx status code³.

What to do when you've been down

1. Find the sender's delivery log, often in a webhooks or developer section.
2. Filter for failed or pending deliveries in the window when your system was down.
3. Fix the cause first. GitHub says that if a webhook delivery fails repeatedly, you should investigate the cause¹.
4. Resend the failed events, or wait for the automatic retry if the sender has one.
5. Check your records against the sender's records to confirm nothing is missing.

Expect repeats

Retries mean the same message can arrive twice. Stripe says webhook endpoints might occasionally receive the same event more than once³. A resend after a retry is one way that can happen.

Your receiving system should handle this calmly. Stripe says you can guard against duplicates by logging the event IDs you've processed and not processing logged events again³.

If an event never arrived at all, Stripe says the API can fetch the records you missed³. That's the fallback when retry windows have closed.

Making a miss less likely

Reply quickly, and process the work afterward. Stripe suggests an asynchronous queue, so that a spike in deliveries doesn't overwhelm your system³. A queue is a waiting line: the receiver notes each message and handles it when it can.

Retry windows end. Once they do, a missed event stays missed until you fetch or resend it.