00 / guide
Missed Stripe webhooks: how to find and replay undelivered events
Your webhook route was down, redirecting or erroring, and Stripe events piled up. Here is how to find them, replay them safely, and hear about it sooner next time.
Free tool: what the outage cost and what Stripe will still retry
01 / what CheckoutAlarm checks
a
Undelivered events
With a read-only restricted key, we list events Stripe couldn't deliver and email you when any are still pending after about 15 minutes. Full secret keys are refused.
b
Endpoints and sales
We also flag endpoints that are disabled, and sales that go quiet for about 48 hours when the previous 14 days say they should still be coming in.
c
Plans
Free: 1 site, checked once a day. Pro: $19 a month, up to 3 sites checked hourly. You prove you own the site first. Compare plans
02 / find what you missed
1
Look at Event deliveries
In Workbench, open Webhooks, pick the endpoint, then the Event deliveries tab. Each event shows Delivered, Pending or Failed. Click one to see the HTTP status code and when the next try is due. Stripe: view event deliveries
2
List undelivered events with the API
Call the List Events API with delivery_success=false, the event types your endpoint listens for, and ending_before set to the last event that was delivered before the outage. Only events from the last 30 days come back, 10 per page by default. Stripe: process undelivered events Stripe API: list events
3
Fix the cause first
Stripe counts any non-2xx answer as a failure, redirects included, and needs TLS 1.2 or higher. Fix the route before you replay, or the replays fail too. Stripe: fix HTTP status codes Our webhook not firing guide walks through the common causes.
03 / replay them safely
a
Resend or process
Click Resend on an event in the Dashboard (up to 15 days after it was created), or run stripe events resend <event_id> --webhook-endpoint=<endpoint_id> (up to 30 days). Stripe: manual retries For a big backlog, Stripe suggests processing the listed events yourself, oldest first. Stripe: process undelivered events
b
Never process an event twice
Your script may run more than once, and Stripe's own retries may arrive while it runs. Record each event ID as processing, then processed, and skip IDs you have already seen. Stripe: process the events
c
Answer the retries with 200
Stripe keeps retrying events you processed by hand, even if a manual resend returned 2xx. When a retry arrives for an event you already handled, skip it and return 200 to stop it. Stripe: manual retries
d
Don't switch the endpoint off to stop the noise
Stripe won't resend events created while a destination is disabled. If it is disabled or deleted when a retry is due, Stripe stops retrying that event. Stripe: event destinations Stripe: automatic retries
04 / questions
- How do I see which Stripe webhook events failed?
- Open the endpoint in Workbench, Webhooks, then the Event deliveries tab. Each event shows Delivered, Pending or Failed, with the HTTP status code. With the API, list events with delivery_success=false.
- How far back can I find missed Stripe events?
- The List Events API returns events from the last 30 days. You can resend an event from the Dashboard for up to 15 days after it was created, or with the Stripe CLI for up to 30 days.
- Does Stripe retry failed webhooks on its own?
- Yes. In live mode Stripe retries for up to three days with exponential backoff. In a sandbox it retries three times over a few hours. If the endpoint is disabled or deleted when a retry is due, Stripe stops retrying that event.
- If I process missed events myself, will Stripe stop retrying?
- No. Stripe still counts them as undelivered and keeps retrying, even after a manual resend returns 2xx. When a retry arrives for an event you already handled, skip it and return 200.
- How do I make Stripe stop retrying an event?
- Answer it with a 2xx. Stripe's docs say to skip events you already processed and return 200 to stop retries. If the endpoint is disabled or deleted when a retry is due, Stripe stops future retries too. Turn it back on before the retry is due and retries go on.
- Are events sent while my endpoint was disabled retried later?
- No. Stripe says it won't try to resend events created while a destination is disabled. List them with delivery_success=false and process them yourself.
- Does Stripe tell me when my webhook keeps failing?
- Stripe's subscription webhook docs say that in live mode it also emails you when a webhook is failing. Check the email address on your Stripe account.
- What does CheckoutAlarm check?
- With a read-only restricted key, it looks for events Stripe still hasn't delivered after about 15 minutes, endpoints that are disabled, and sales that go quiet for about 48 hours compared with the prior 14 days. It doesn't alert when an account has no endpoints at all. It also checks one page. Free checks 1 site once a day. Pro is $19 a month for up to 3 sites checked hourly.
05 / where CheckoutAlarm fits
CheckoutAlarm reads the same undelivered-events list with a read-only key and emails you when events are still pending after about 15 minutes, so you can fix the route while Stripe is still retrying. It does not replay or change anything in your Stripe account.
CheckoutAlarm is new. It only checks sites you prove you own. How to verify
Watch my app free06 / sources
- Stripe: process undelivered events (delivery_success, ending_before, 30 days)
- Stripe: view event deliveries (Event deliveries tab, status codes)
- Stripe: automatic retries (up to three days in live mode)
- Stripe: manual retries (Dashboard 15 days, CLI 30 days)
- Stripe API: list all events
- Stripe: event destinations (disabled destinations)
- Stripe: subscription webhooks (failing-webhook email in live mode)
Docs checked on Oct 20, 2026.