Replay

Replay is re-running a retained event with the same input — typically after fixing a bug that caused the original to fail or after changing the consumer's logic.

The basic pattern is straightforward: pull a stored event, re-deliver it to the destination, observe the result. The hard part is making replay deterministic — re-running with the exact same input that produced the original failure.

Why deterministic replay is harder than it sounds

Three things have to be true for replay to reliably reproduce the original failure:

1. The original payload bytes are persisted (not just the parsed payload — the bytes the sender actually sent)
2. The transformation applied to the payload is persisted (not the current transform config — the snapshot of what was applied at original delivery time)
3. The replay mechanism uses both (not the current config plus the persisted payload, which would produce a different result)

Most home-grown webhook systems get one or two of these right and miss the third. The result: replays produce different outputs than the original, and the fix-and-verify loop becomes guesswork.

Why agents need replay more than classical software

Classical webhook handlers are deterministic — same payload in, same response out. AI agents aren't — the LLM's output varies, tool calls have real-world side effects, retries cost tokens. Without deterministic replay, you can't reproduce a customer's failure to fix it.

Hooksbase persists raw payloads and dispatch snapshots per delivery while they are inside the payload retention window, and exposes one-click replay from the dashboard.

For the deeper read: Deterministic replay for agents.