Webhook Replay
Sending an old webhook event through the receiver again so work missed during an outage or bug can catch up.
See it
What it is
A webhook replay sends a past event through the receiver again. Stripe and GitHub both let operators redeliver events, and mature integrations keep their own event inbox so a failed delivery can be retried after a bug or outage is fixed. It is the recovery button for work that never finished the first time.
Reach for replay when the endpoint was down, a consumer crashed, or bad code rejected a valid payload. Store the verified event ID, original payload, receipt time, processing result, and last error before doing business work. Then replay through the same queue and handler as live traffic so recovery does not become a second, untested code path.
Replay means duplicate delivery by design. The consumer must deduplicate by event ID and record attempts separately from outcomes. A failed event that never completed should run; an event already marked complete should normally remain a no-op unless an audited force-reprocess action is explicitly requested. Old events can also describe stale intent, so refetch current state before applying destructive changes.
Ask AI for it
Add webhook replay for Stripe events. Persist each verified Stripe event.id, its raw JSON payload, received_at, processing status, attempt count, and last error before enqueueing it in BullMQ. Add an admin-only POST /admin/webhooks/{eventId}/replay endpoint that creates an audited replay attempt and sends the stored event through the same idempotent consumer as live traffic. Make completed event IDs no-ops by default, require a separate force flag and reason to reprocess one, and test outage recovery plus two simultaneous replay requests.