If you’ve triggered a manual resend on a failed Stripe webhook and assumed that clears the queue, it doesn’t. The resend fires an additional delivery attempt alongside whatever retry schedule Stripe already has running—it doesn’t cancel it.

What actually happens

When a webhook delivery fails, Stripe retries it for up to 3 days in live mode using exponential back-off. A sandbox gets three retries over a few hours. That schedule runs independently of anything you do manually.

If you go into the Dashboard and hit resend, that attempt is additive. Even if the manual resend gets a 2xx back, Stripe’s automatic retries continue on their own schedule. One documented way to stop future retries is to process the undelivered event through the method Stripe documents for that purpose.

Manual resends are available for up to 15 days in the Dashboard and up to 30 days with the CLI after the original event was created.

What your endpoint has to handle

Because the same event can arrive more than once—through the combination of automatic retries, manual resends, or both—Stripe explicitly recommends logging event IDs and skipping any ID you’ve already processed. Without that, a payment confirmation or subscription update could be acted on twice.

Event order is a separate concern. Stripe does not guarantee that events arrive in the order they were generated, so any workflow that assumes, say, customer.subscription.updated always arrives before invoice.paid will break under real conditions. Each event needs to be handled on its own merits.

For endpoints that see volume spikes—subscription renewals at the start of a month are a common case—Stripe recommends processing incoming events with an asynchronous queue rather than synchronously, since a burst of deliveries can overwhelm a synchronous handler.

The short checklist

  • Deduplicate by event ID. Store IDs of processed events and ignore repeats.
  • Don’t assume order. Handle each event as if prior events may not have arrived yet.
  • Use an async queue if your endpoint handles any meaningful volume.
  • Don’t rely on a manual resend to halt retries. If you need retries to stop, process the event through the documented undelivered-events flow.

A manual resend is a useful debugging tool, but it’s not a control mechanism for Stripe’s retry engine. Building the receiver to be idempotent and order-agnostic is the only durable fix.