Replay failed webhooks — safely, and with context

Replay re-sends the exact payload a provider originally delivered to your endpoint. It is the fastest way to recover a webhook you dropped or mishandled — you fix the bug, replay the captured delivery, and the event finally lands. But replay runs a real event a second time, so doing it blindly can be worse than the original failure.

Why manual replay can be risky

Re-running an event re-runs its side effects. If your handler is not idempotent, a replayed delivery can:

• Double-charge or double-credit — a replayed invoice.paid that already partially processed can bill or refund twice.
• Duplicate records — a second order.created inserts a second order, ships a second parcel, or sends a second confirmation email.
• Re-trigger downstream webhooks — your handler emits its own events, so one replay can fan out into many.
• Overwrite newer state — replaying a stale subscription.updated can roll back a change that already happened.

Duplicate side effects and idempotency

The safe path is an idempotent handler: processing the same event twice produces the same result as processing it once. Most providers send a stable identifier — an event id, a delivery id, or an Idempotency-Key — that you can record and check before acting. If you have already handled that id, a replay becomes a no-op instead of a duplicate. If your handler is not idempotent yet, treat replay as a manual, one-at-a-time operation and verify each result.

What to check before you replay

• The original request — the exact payload and headers, so you know what will be re-sent.
• The target response — a 500 means your handler threw; a 4xx may mean the request itself was rejected.
• The attempts — whether the provider (or a previous replay) already delivered this event, so you do not process it twice.
• Idempotency behaviour — whether re-running this specific event is safe, or needs guarding first.

A safe-replay checklist

1. Confirm the root cause is fixed and deployed — see webhook debugging.
2. Open the failed delivery and read its request and response.
3. Check the attempt history so you are not re-processing an event that already succeeded.
4. Confirm your handler is idempotent for this event, or plan to verify the result by hand.
5. Replay a single delivery first, then verify the downstream state changed exactly once.
6. Only then replay the rest.

The full walkthrough lives in how to replay a failed webhook safely.

How HookWatch helps

Because HookWatch captures the exact request, response, and attempt timeline for every delivery, it gives you the context each replay needs — before you click replay, not after. You re-send the captured payload to your endpoint with one action, verify the result, and move on. It works with any provider that sends HTTP webhooks, including Stripe. Replay is a recovery tool, not a guarantee: HookWatch shows you what you are about to re-run so you can decide whether it is safe.