Stripe webhook returned HTTP 500: what happens next?

An HTTP 500 tells Stripe that your webhook endpoint did not complete a successful protocol-level delivery. Stripe treats that attempt as failed and may retry it automatically. The response is important evidence, but it is not a complete account of what happened inside your application.

What Stripe sees

From Stripe's perspective, a 500 is a non-2xx response. Its live-mode retry process can try the Event again, with the timing controlled by Stripe's delivery policy. Your endpoint should return a successful response promptly when it has safely accepted the Event, rather than holding the request open for every downstream operation.

A 500 does not prove that nothing happened

A handler can write to a database, call another service, or enqueue work and then fail before returning. A timeout can have the same ambiguity: the server may have completed an operation even though the sender did not receive the response. Retrying a handler after that point can repeat a side effect.

For example, charging a customer, sending an email, or changing a subscription before an exception produces a 500 does not become safe merely because Stripe will retry. Durable business identity and idempotent operations are still required.

Separate transient outages from deterministic bugs

Repeated 500s during a database outage may resolve when the dependency recovers. Repeated 500s from a validation bug will not. Preserve the original Event and each delivery attempt so an operator can see the difference, fix the underlying issue, and choose a deliberate recovery path instead of guessing from the latest error alone.

A reliability boundary can retain responsibility while downstream work is unavailable. That makes retry and later replay visible without rewriting the original receipt or pretending the endpoint's business processing completed.

Practical response

1. Record the provider Event identity and verification result.
2. Persist the accepted body before doing slow business work.
3. Return a response within the provider's timeout expectations.
4. Use idempotent processing for every retried or replayed Event.
5. Inspect attempt history before manually replaying an Event.

Further reading: Stripe's webhook retry guidance and Stripe's guidance on quickly returning a 2xx response.