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. Replay is the manual counterpart to the automatic retries every delivery already gets. Use it when a destination was unavailable long enough to exhaust them, 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.
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.
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.
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.
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.
Navigate to the forwarder that should receive the replayed events. Replay always targets the forwarder whose history you are viewing.
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.
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.
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.
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.
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.
Pending
The job has been created and is waiting to start. You can cancel a pending job at any time.
Estimating
Repost is preparing the job and resolving the matching event set. The total count may be unavailable until this phase completes.
Processing
The job is actively delivering replay attempts to the forwarder destination at the configured rate.
Paused
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.
Completed
The job finished processing its full batch. Terminal: cannot be cancelled or resumed.
Cancelled
The job was cancelled before it finished. Terminal: events that were not yet processed were not delivered.
Pause, resume, and cancel#
Available for a processing job. Pausing stops delivery immediately and holds the remaining batch for when you resume.
Available for a paused job only. If the forwarder itself is also paused, resume the forwarder before resuming the replay job.
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.
| Field | Meaning |
|---|---|
Processed | Successful plus failed replay delivery attempts so far. |
Success | Delivery attempts that completed successfully. |
Failed | Delivery attempts that were tried but did not succeed. |
Pending | Events still waiting in the replay batch. |
Total | The full batch size. May be unavailable while the job is estimating. |
Rate | The configured replay throughput in requests per second. |
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#
| Limit | Value |
|---|---|
| Maximum selected rows (Replay Selected) | 100 rows |
| Replay rate range | 5 – 500 requests per second |
| Active replay jobs per forwarder | 1 |
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#
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.
Check whether your destination handles duplicate events gracefully. Idempotent destinations can receive the same event more than once without creating duplicate side effects.
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.
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#
Replay buttons are disabled
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.
Replay All processes fewer events than expected
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.
Failed-delivery rows disappear after replay
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.
Resume is disabled
The job must be in a paused state, and the forwarder itself must not be paused. Resume the forwarder before resuming the replay job.
Failed count keeps rising
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.