Skip to main content
Replay re-delivers stored events to a forwarder without contacting the original webhook provider. Repost reads the events from your history, constructs the delivery attempts, and sends them through the forwarder’s destination exactly as a live event would be — including any transforms your function applies. Use replay when a destination was unavailable during initial delivery, when you deployed a fix to your function code, or when a forwarder configuration change means previously delivered events need another pass.
Replay sends real traffic to your destinations. Confirm that your destination can tolerate receiving the same event more than once before starting a broad replay.

​
Choose a replay source

A replay job always belongs to one forwarder. The source determines which events enter the job.

One event

Open an event or forward detail drawer and replay that single event. From bucket history, choose one or more active, unpaused forwarders — Repost creates a separate job for each selected forwarder.

Selected history rows

Select rows in forwarder history, then start Replay Selected. Repost deduplicates the selected rows by event ID before creating the job. The table caps selection at 100 rows.

Filtered history

Use Replay All from forwarder history to replay every event matching your current query and time window. Replay All excludes replay-created attempts so repeated jobs do not replay their own output.

Failed deliveries

Replay directly from the failed-deliveries view when exhausted delivery items should be sent through the forwarder again. Completed jobs remove the source rows from the failed-delivery list.

​
Replay from forwarder history

Forwarder history is the primary replay surface for filtering and replaying sets of events.
1

Open the forwarder's History page

Navigate to the forwarder that should receive the replayed events. Replay always targets the forwarder whose history you are viewing.
2

Narrow the time window

Use the date and time picker, the timeline histogram, and the query editor to define your working set. Forwarder history opens with a Today window by default. Replay All uses the current query and the window shown by the picker.
3

Select rows or choose Replay All

For a precise selection, check the rows you want and click Replay Selected. For the full filtered set, click Replay All. Replay All previews a count of matching delivery attempts and deduplicates them by event ID before the job starts.
4

Review the preview

The Replay All dialog freezes the end time when it opens, estimates matching delivery attempts, and shows the unique event count after deduplication. Confirm the numbers match your intent before continuing.
5

Set the replay rate

Choose a throughput between 5 and 500 requests per second in steps of 5. The default is 50 requests per second. Use a lower rate for destinations that recently recovered or have strict rate limits.
6

Start the job

Confirm and start the replay job. Monitor progress from the forwarder’s Replay Jobs page or from the active job banner shown in history views.
Start with a narrow query such as status:FAILED or a specific received_at range. Broaden the query only after the preview count matches your expectation.

​
Replay job states

Replay jobs move through a defined lifecycle. You can monitor, pause, resume, and cancel jobs from the forwarder’s Replay Jobs page.
The job has been created and is waiting to start. You can cancel a pending job at any time.
Repost is preparing the job and resolving the matching event set. The total count may be unavailable until this phase completes.
The job is actively delivering replay attempts to the forwarder destination at the configured rate.
Delivery is stopped until you resume the job. A paused job still counts as the active replay job for the forwarder, blocking any new replay from starting.
The job finished processing its full batch. Terminal — cannot be cancelled or resumed.
The job was cancelled before it finished. Terminal — events that were not yet processed were not delivered.

​
Pause, resume, and cancel

Pause

Available for a processing job. Pausing stops delivery immediately and holds the remaining batch for when you resume.

Resume

Available for a paused job only. If the forwarder itself is also paused, resume the forwarder before resuming the replay job.

Cancel

Available until the job reaches a terminal state. Completed and already-cancelled jobs cannot be cancelled again.
A forwarder can have only one active replay job at a time. A pending, estimating, processing, or paused job all block new replay jobs for the same forwarder. Wait for the active job to finish, or cancel it before starting a new one.

​
Monitor job progress

The replay job detail page shows live counts as the job runs.
A terminal job may show Finalizing briefly while the final counts settle. Check the job detail page for the authoritative delivery breakdown.

​
Deduplication

Repost deduplicates by event ID when you start a replay job. If the same event appears multiple times in your selected rows or filtered history — for example, from multiple failed attempts — Repost ensures the event is delivered only once per job. This prevents a single event from being sent to your destination twice in one replay run.

​
Replay limits

​
Forwarder deletion and replay

Repost blocks forwarder deletion while a replay job is pending, estimating, processing, or paused. Cancel or wait for the active job to reach a terminal state before deleting the forwarder.

​
Best practices

1

Filter precisely first

Write a specific query and a tight time range before using Replay All. Review the preview count and confirm it reflects only the events you intend to redeliver.
2

Verify idempotency

Check whether your destination handles duplicate events gracefully. Idempotent destinations can receive the same event more than once without creating duplicate side effects.
3

Use a conservative rate

Start at a low rate — 5 to 10 requests per second — when a destination recently recovered, has strict rate limits, or you are uncertain of its current capacity.
4

Watch the job while it runs

Keep the replay job page open. If the failed count rises unexpectedly, pause the job, inspect the forward history, fix the destination issue, and then resume.

​
Troubleshooting

For Replay Selected, ensure you have checked at least one row. For Replay All, confirm the current filtered view has matching rows. If a replay job is already active for the forwarder, wait for it to complete or cancel it first.
The current query and time window define the job source. Replay All deduplicates by event and excludes replay-created attempts. Remove the last clause or widen the time window if the job source is too narrow.
This is expected. Completed failed-delivery replay removes its source rows from the failed-delivery list so the same item is not replayed a second time from that view.
The job must be in a paused state, and the forwarder itself must not be paused. Resume the forwarder before resuming the replay job.
The destination is still returning errors or timing out. Pause the job, open forwarder history, inspect recent attempts for error details, resolve the destination issue, and then resume the job.