A Stripe webhook fails when your endpoint returns a non-2xx HTTP response or times out. You can see failed deliveries immediately in the Stripe Dashboard under Developers → Webhooks → Recent Deliveries. Stripe retries silently for up to 72 hours before notifying you — so polling the delivery log directly is the only way to know within minutes.

How to Know When a Stripe Webhook Fails

May 20, 2026 · 6 min read · Stripe monitoring

A Stripe webhook fails and you don't find out for 72 hours. Your invoice.payment_failed handler never ran. Subscriptions are still active in your database even though Stripe already tried to charge the card and failed. A customer emails in wondering why their feature access didn't update. You have no idea it happened.

This is what Stripe's silent retry behavior looks like from the outside. Here's how it works, why it catches engineers off guard, and how to detect failures within minutes instead of days.

How does Stripe handle a failed webhook delivery?

When your endpoint returns a non-2xx HTTP response — or times out after 30 seconds — Stripe marks the delivery as failed and schedules a retry. The retry schedule follows an exponential backoff:

• Immediately
• 5 minutes later
• 30 minutes later
• 1 hour later
• 2 hours later
• 4, 8, 16, 24, 48, 72 hours later

That's up to 11 attempts over 72 hours. You receive no alert during this window — only a notification email after the final retry fails. If your endpoint recovers partway through, Stripe will succeed on a later retry and never tell you about the failures.

Where does Stripe log webhook delivery failures?

Every delivery attempt is logged in the Stripe Dashboard under Developers → Webhooks → [your endpoint] → Recent Deliveries. Each entry shows:

• Event type (e.g. invoice.payment_failed)
• Delivery status: Success or Failed
• HTTP response code your endpoint returned
• Response body (first 1 KB)
• Timestamp
• A button to manually redeliver the event

Stripe also exposes this data programmatically via the Events API — which is what monitoring tools use to detect failures without you having to check the dashboard manually.

Why doesn't Stripe send an alert when the first delivery fails?

The assumption baked into Stripe's design is that transient endpoint failures (a deploy, a server restart, a brief 503) will self-recover before the retries run out. Alerting on every first failure would generate noise. The problem is that non-transient failures — a misconfigured handler, a signature verification bug, a missing environment variable in production — also get silently retried, and you have no signal until 72 hours later.

For events like invoice.payment_failed or customer.subscription.deleted, 72 hours of silent failure means customer state in your database drifts from reality for three days before you're notified.

How can you detect a failed Stripe webhook within minutes?

There are two approaches:

Option 1: Poll the Stripe Events API yourself

Using a read-only Stripe API key, you can poll the Events API every few minutes and check delivery status for each event. A failed delivery looks like this:

# Stripe Event object — delivery failure signal
event.request.id = null          # null means Stripe initiated (not your code)
event.pending_webhooks > 0      # still has undelivered endpoints
# Check webhook delivery status via:
GET /v1/events/{id}
# Each event lists webhooks[] with status per endpoint

This works but requires you to maintain the polling infrastructure, handle Stripe API rate limits, de-duplicate events you've already seen, and build your own alerting.

Option 2: Use a dedicated webhook monitor

Webhook Guardian connects to your Stripe account via read-only OAuth and polls the Events API every 5 minutes. When it detects a failed delivery, it fires a Slack alert with the event type, error code, retry count, payload preview, and a one-click redeliver link — before Stripe has even attempted its second retry.

No infrastructure to maintain. No Stripe API key management. Revocable at any time from your Stripe dashboard.

What events are most dangerous to miss?

Not all Stripe webhooks are equal in urgency. The ones that cause the most damage when missed:

• invoice.payment_failed — subscription renewal failed, customer should be notified and access should be restricted
• customer.subscription.deleted — subscription cancelled, your database needs to reflect this
• customer.subscription.updated — plan changed, feature access needs updating
• checkout.session.completed — new purchase, provisioning must run
• charge.refunded — refund processed, accounting and access systems need updating

If any of these fails silently, your customer's experience degrades while your database shows the wrong state.

How do you redeliver a failed Stripe webhook?

From the Stripe Dashboard: Developers → Webhooks → [endpoint] → Recent Deliveries → [failed event] → Resend. Stripe will immediately attempt redelivery to your endpoint.

Programmatically, you can trigger a redeliver via the API. Webhook Guardian includes a one-click replay link in every Slack alert, so you can trigger the redeliver without leaving the alert.

FAQ: Stripe webhook failure detection

Monitor Stripe webhook failures automatically. Connect Stripe to Webhook Guardian and get alerted within 5 minutes of any failed delivery — with the event payload and a one-click replay link. Start free for 14 days →