> ## Documentation Index
> Fetch the complete documentation index at: https://repost.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Replay Webhook Events to a Forwarder Without Retriggering

> Redeliver stored Repost events to a forwarder without retriggering the provider — replay one event, a selection, or a filtered history set.

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.

<Warning>
  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.
</Warning>

## Choose a replay source

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

<CardGroup cols={2}>
  <Card title="One event" icon="play">
    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.
  </Card>

  <Card title="Selected history rows" icon="list-checks">
    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.
  </Card>

  <Card title="Filtered history" icon="search">
    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.
  </Card>

  <Card title="Failed deliveries" icon="archive-restore">
    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.
  </Card>
</CardGroup>

## Replay from forwarder history

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

## 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.

<AccordionGroup>
  <Accordion title="Pending" icon="clock">
    The job has been created and is waiting to start. You can cancel a pending job at any time.
  </Accordion>

  <Accordion title="Estimating" icon="loader">
    Repost is preparing the job and resolving the matching event set. The total count may be unavailable until this phase completes.
  </Accordion>

  <Accordion title="Processing" icon="play">
    The job is actively delivering replay attempts to the forwarder destination at the configured rate.
  </Accordion>

  <Accordion title="Paused" icon="pause">
    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.
  </Accordion>

  <Accordion title="Completed" icon="check">
    The job finished processing its full batch. Terminal — cannot be cancelled or resumed.
  </Accordion>

  <Accordion title="Cancelled" icon="ban">
    The job was cancelled before it finished. Terminal — events that were not yet processed were not delivered.
  </Accordion>
</AccordionGroup>

### Pause, resume, and cancel

<CardGroup cols={3}>
  <Card title="Pause" icon="pause">
    Available for a processing job. Pausing stops delivery immediately and holds the remaining batch for when you resume.
  </Card>

  <Card title="Resume" icon="play">
    Available for a paused job only. If the forwarder itself is also paused, resume the forwarder before resuming the replay job.
  </Card>

  <Card title="Cancel" icon="ban">
    Available until the job reaches a terminal state. Completed and already-cancelled jobs cannot be cancelled again.
  </Card>
</CardGroup>

<Note>
  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.
</Note>

## 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.             |

<Note>
  A terminal job may show **Finalizing** briefly while the final counts settle. Check the job detail page for the authoritative delivery breakdown.
</Note>

## 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Replay buttons are disabled" icon="circle-off">
    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.
  </Accordion>

  <Accordion title="Replay All processes fewer events than expected" icon="search-x">
    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.
  </Accordion>

  <Accordion title="Failed-delivery rows disappear after replay" icon="archive">
    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.
  </Accordion>

  <Accordion title="Resume is disabled" icon="pause-circle">
    The job must be in a paused state, and the forwarder itself must not be paused. Resume the forwarder before resuming the replay job.
  </Accordion>

  <Accordion title="Failed count keeps rising" icon="triangle-alert">
    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.
  </Accordion>
</AccordionGroup>