If you process Stripe subscriptions and have never opened Workbench → Webhooks → Event deliveries (or the older Developers → Webhooks → Attempts view), there's a chance you have failed deliveries from the last 30 days you don't know about. This is worth checking, so let's go through what to look for.

How Stripe delivers events

When a customer's payment fails, Stripe sends a POST to your webhook endpoint with an invoice.payment_failed event. Here's what happens next:

• Your endpoint should quickly return a 2xx response. Stripe doesn't publish an exact timeout in seconds, but the docs say "quickly return 2xx prior to any complex logic".
• If you time out, return non-2xx, or the endpoint is unreachable, Stripe marks the attempt as failed. Any non-2xx triggers retries, including 4xx — a common myth is that Stripe only retries on 5xx, but the docs say "if your endpoint previously replied with a non-2xx status code".
• Retries happen with exponential backoff. In live mode, for up to 3 days. In sandbox/test mode, 3 attempts over a few hours. Stripe doesn't publish the exact retry schedule in the docs, but in practice it works out to roughly 16 attempts across those 3 days (first retry within an hour, then ~12 hours, then daily). You can see the next scheduled retry per event in the Event deliveries tab.
• After ~3 days of continuous failures, Stripe disables your endpoint automatically and emails you. After disabling, new events are not delivered to that endpoint at all until you re-enable it. This is the single biggest source of "tiny drops" turning into "we lost a whole week of payment_failed events" — the retries didn't just expire, the endpoint went dark.
• If all retries fail across the 3-day window (but the endpoint is still active), the event is not lost: you can manually resend it within 30 days via Stripe CLI, or within 15 days via Dashboard.

The catch: "not lost" only works if you know the event came in and was failed. If you don't check Event deliveries regularly, you find out about misses when a customer messages "why did you charge me, I cancelled a month ago" or when a monthly churn audit shows a hole in your MRR.

What actually causes events to get lost

Something I underestimated at first: Stripe retries for 3 days. That means a short 30-second deploy window on its own won't cause loss. Stripe will try again in an hour, in a few hours, the next day. You have a huge window to get the endpoint back up.

Real losses come from persistent problems that outlast the retry window — or worse, problems that get the endpoint auto-disabled. Here they are:

1. Endpoint persistently broken. Most common in my experience. For example, you rotated the Stripe webhook secret on your app side but didn't update it in the Stripe Dashboard. Every event arrives, signature verify fails, you return 400. Over 3 days, all retry attempts fail the same way, then Stripe disables the endpoint. After that, new events stop coming entirely. If you're not looking at Event deliveries, you don't find out until someone complains.

2. Firewall blocking Stripe IPs. Cloudflare WAF, AWS security groups, corporate firewalls — any of them can start dropping legitimate Stripe requests after a rules change. Stripe sends requests from a pool of IP addresses that changes over time. If you accidentally whitelisted only the old set, new IPs start receiving 403, and you don't see it. Stripe itself recommends against relying on IP allowlisting alone for this reason, and pairs it with signature verification.

3. Endpoint URL changed. You moved from /api/webhook to /v2/webhook or switched domains, but didn't update the URL in Stripe Dashboard. All events go to the old URL, get 404, retry for 3 days, endpoint gets disabled. I've watched a teammate ship this exact change on a Friday afternoon and find out on Monday.

4. Endpoint disabled or deleted at the moment of retry. If your endpoint is disabled or deleted when Stripe attempts a retry, that specific event is dropped. The nuance: if you disable and then re-enable the endpoint before the next retry attempt, future retries continue normally. The real risk is being disabled across the entire retry window — for example, you manually disabled an endpoint to fix something and forgot to turn it back on.

5. Sustained DB connection pool exhaustion. Not a one-minute spike, but constant load where the handler regularly waits for a DB connection longer than Stripe's timeout. If that happens for more than 3 days, events drop and the endpoint gets auto-disabled. Short-term exhaustion is usually covered by retry.

Short deploy windows and one-off OOM kills rarely cause loss precisely because the retry window is long. The dangerous ones are persistent problems your health checks don't catch — especially the ones that escalate into auto-disable.

How to check how much you're losing

Workbench → Webhooks → pick a specific endpoint → Event deliveries tab. (If you're still on the older Developers Dashboard, it's Developers → Webhooks → your endpoint → Attempts. Stripe is migrating everyone to Workbench, but both still work.) You'll see recent delivery attempts with success/failed status and response codes.

What to look for:

• failed status over the last 30 days
• Grouped by event type — which events fail more often
• Time pattern — are fails clustered during deploy windows?
• Any "endpoint disabled" notification emails sitting in your inbox that you ignored

Next, compare against your own log of received webhooks. If you're not logging each webhook receipt separately, start now. Minimal middleware:

app.post('/webhook/stripe', (req, res) => {
  console.log('webhook received', {
    event_id: req.body.id,
    event_type: req.body.type,
    livemode: req.body.livemode,
    received_at: new Date().toISOString()
  })
  // ... handler
})

A week later, compare event counts in Stripe Dashboard vs your log. The diff is your drop rate. If it's zero, great. If it's non-zero, you now have a concrete number and a list of specific event_ids that got dropped, and you can dig into why.

What to do to stop losing events

The main pattern: ACK fast, process async. Your webhook handler should do the minimum work and return 200 immediately. Heavy processing goes into a background queue.

app.post('/webhook/stripe', async (req, res) => {
  // 1. verify signature
  const event = stripe.webhooks.constructEvent(
    req.rawBody,
    req.headers['stripe-signature'],
    process.env.STRIPE_WEBHOOK_SECRET
  )

  // 2. persist for idempotency (event.id is the right key — Stripe
  //    explicitly recommends "logging the event IDs you've processed"
  //    to guard against duplicates from retries and manual resends)
  await db.insert(stripe_events).values({
    id: event.id,
    type: event.type,
    payload: event,
    received_at: new Date()
  }).onConflictDoNothing()

  // 3. enqueue and respond immediately
  await queue.add('process-stripe-event', { event_id: event.id })

  res.status(200).send('ok')
})

What this gives you:

• The handler returns 200 in milliseconds
• Even if downstream processing falls over in the queue, the event is in your DB
• Using event.id as the idempotency key lets you safely replay

Replay missed events. If you find failed events in the Dashboard, two ways to resend them:

• Dashboard: open a specific event → Resend button. Available for 15 days after the event is created.
• Stripe CLI: stripe events resend <event_id> --webhook-endpoint=<endpoint_id>. Available for 30 days after the event is created.

Important nuance from the Stripe docs: a manual resend does not cancel the automatic Stripe retry cycle. So your endpoint may receive the same event twice, once from Stripe's retry, once from your manual resend. That's why an idempotency check on event.id is mandatory.

Reconcile via the Events API. Stripe itself recommends not relying solely on webhook delivery for critical data, and has a dedicated guide for this called Process undelivered webhook events. The pattern: periodically call the List Events API filtered by event type and time window, and compare against what your DB has. For example, to find invoice.payment_failed events in a window:

GET /v1/events?type=invoice.payment_failed&created[gte]=<unix_ts>&created[lt]=<unix_ts>

This is more reliable than hoping every webhook made it through. For a production billing system, running this nightly as a safety net is cheap insurance.

Email notifications about failures. Stripe already sends these automatically when your endpoint is failing or gets disabled — you don't need to enable anything. What you do need to check:

• That those emails are going to a human who actually reads them (Settings → Team and Security)
• That they're not silently routed to spam
• That the recipient knows what to do when one arrives

I've seen teams where the webhook-failure emails were going to a shared noreply@ inbox no one had opened in 8 months.

Optional: independent alerting. On top of Stripe's emails, you can:

• Run a third-party health check (UptimeRobot, Better Stack) on the webhook URL itself for response time.
• Push your own webhook-received metric to Datadog/Grafana and alert when failed_attempts > N in a window.

The point

invoice.payment_failed events matter more than most of your GitHub PRs and Jira issues, yet they usually get the least monitoring. Open Stripe Dashboard now and look at Event deliveries for the last 30 days. If there are failed records you've never seen, you have a gap in your data worth closing.

The short version: check your Event deliveries tab, make sure your handler is ACK-fast with async processing and idempotency on event.id, and run a nightly reconcile against the List Events API for the events that matter most. That closes 90% of the nastiest cases where events go silent.

P.S. I'm building a small Telegram bot called devpinger that delivers engineering alerts to one chat — GitHub PRs, CI failures, Jira issues already work; Stripe webhook failures and Sentry alerts are next. MIT, in case it's useful.