Replay

Replay re-delivers the original request — same payload, same headers, same path — through your currently active tunnel.

Replay is the action of re-sending a previously captured webhook event to your code, using the exact same payload, headers, and path as the original. It is the most useful action in the dashboard because it lets you reproduce a failure on demand, in your own environment, with your own logs.

What gets replayed

• The request method (almost always POST)
• The request path (everything after the alias domain)
• The request body (the original bytes, not a re-serialization)
• The request headers (every original header — including signature headers like Stripe-Signature)
• The original arrival time is not preserved. The replay is a fresh event.

The replay is delivered through whichever tunnel is currently online. If your tunnel is offline, the relay queues the replay and delivers it as soon as you reconnect.

How to replay

From the event inspector, click the Replay button. The action is one click. The dashboard shows the new attempt as it lands.

What you see after replay

The event is updated in place. The original event row stays where it was, but a new attempt is appended. The inspector now shows two attempts side by side:

• Original attempt — the one that came from the provider, with its original response, headers, and timing.
• Replay attempt — the one you triggered, with the new response, headers, and timing.

If the original failed because of, say, a signature verification bug, the replay attempt should now show a different response (a 200 from your fixed code) — and you can see them both in the same view.

Replay is per-event, not per-alias

There is no "replay all events for this alias" button (yet). Replay is deliberately granular. Most debugging starts with a single failing event, and replaying one event is much less risky than mass-replaying.

The exception is the "replay all queued" bulk action, which only replays events that were queued because the tunnel was offline. Those events were never delivered to your code, so there is no double-execution risk.

Replay through the API

Replay is also a single API call:

POST /api/v1/events/{id}/replay
Authorization: Bearer <token>

Returns the new event record. See the events API for details.

Share and replay

A shared event has its own replay endpoint that does not require auth:

POST /api/v1/events/shared/{token}/replay

This is what your teammates or customers hit when they want to reproduce a problem in their own environment. The replay goes to your currently active tunnel, not theirs — they are triggering a replay against your code.

Replay caveats

• The original delivery time is lost. The replay has a fresh receivedAt timestamp.
• Provider retries are not visible. If Stripe retries the same event 5 minutes after the original failure, that's a new event in your stream, not a replay. Replay is your action, separate from provider behavior.
• Replay is not idempotency. Replay does not add an X-FixedHook-Replay header or anything like that. Your code has no way to know it's a replay unless you look at the event metadata in the dashboard.