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

# Manage Failed Webhook Deliveries in Repost Dead-Letter Queue

> Inspect, replay, and archive failed forwarder delivery attempts parked in the Repost dead-letter queue after all automatic retries are exhausted.

Failed deliveries are the delivery records that land in Repost's dead-letter queue after automatic retries can no longer continue. When a destination keeps returning errors until the forwarder exhausts its configured retry attempts, or when a function's error policy is set to **Send to failed deliveries**, the resulting record parks here waiting for your action. You decide whether to replay the event or archive it as no longer actionable.

<Note>
  Failed deliveries are available only for **queued bucket forwarders**. Proxy buckets do not expose this view because proxy delivery has a single synchronous response with no retry queue.
</Note>

## What sends an event to failed deliveries

An event arrives in the failed-delivery queue when any of the following occur:

<CardGroup cols={3}>
  <Card title="Retries exhausted" icon="mail-warning">
    The destination returned connection failures, `408`, `429`, or `5xx` responses on every attempt until the forwarder reached its configured maximum retry count.
  </Card>

  <Card title="Function error policy" icon="code">
    A function attached to the forwarder threw an error and the forwarder's error policy is set to **Send to failed deliveries** rather than skipping or retrying.
  </Card>

  <Card title="One event, one forwarder" icon="route">
    Each failed-delivery row belongs to exactly one event and one forwarder. If the same event failed across two forwarders, you see two separate rows.
  </Card>
</CardGroup>

## Inspect a failed delivery

Before you act, open the detail view to understand why delivery failed.

<Steps>
  <Step title="Open the forwarder's Failed Deliveries page">
    Navigate to the forwarder that owns the failed destination. The failed-delivery list is scoped to that forwarder.
  </Step>

  <Step title="Filter the list">
    Use the date filter and pagination controls to find the records you want. Date filters are applied by calendar day. The visible hit count reflects the current filter.
  </Step>

  <Step title="Open a row">
    Click any row to open the detail view. The detail is built from the latest unarchived failed-delivery record for that event and forwarder.
  </Step>

  <Step title="Read the detail">
    The detail view shows the original event request, the forwarder and destination URL, every delivery attempt with its status and response, the last error code and message, function execution details if applicable, and timestamps and duration for each attempt.
  </Step>

  <Step title="Decide: replay or archive">
    Replay if the destination should receive the event again. Archive if the event is no longer actionable and you want to remove it from the queue.
  </Step>
</Steps>

## What the detail view contains

| Field             | What you see                                                                                                                       |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Event**         | Event ID, HTTP method, path, request headers, request body, and the time the failed item was created.                              |
| **Forwarder**     | Forwarder ID, name, and target URL.                                                                                                |
| **Attempts**      | Every delivery attempt — attempt number, status, destination response status, error code, error message, timestamps, and duration. |
| **Last response** | The final response or error that caused Repost to stop retrying and place the item here.                                           |

## Replay failed deliveries

Replaying a failed delivery re-submits the event to the same forwarder. Repost creates a new delivery attempt and, when it succeeds, removes the item from the failed-delivery list.

<CardGroup cols={2}>
  <Card title="Replay Selected" icon="list-checks">
    Select up to 100 rows in the table, choose a replay rate, and start **Replay Selected**. The replay job removes the source rows from the failed-delivery list after it completes.
  </Card>

  <Card title="Replay All" icon="rotate-ccw">
    Replays the current failed-delivery set for the forwarder. Date filters are applied by calendar day. The final count can change if items are added, replayed, or archived before the job finishes processing.
  </Card>
</CardGroup>

<Tip>
  Watch the replay job page for real-time success, failure, pending, and rate counts while a failed-delivery replay is running.
</Tip>

<Note>
  If the current date filter matches no failed deliveries, **Replay All** does not create an empty job — Repost rejects the request instead. A forwarder can have only one active replay job at a time, so failed-delivery replay is blocked while another job is pending, estimating, processing, or paused.
</Note>

## Archive failed deliveries

Archive dismisses a failed-delivery record without sending any traffic to the destination. Archived rows are removed from the failed-delivery list permanently. The underlying event remains visible in bucket history.

<AccordionGroup>
  <Accordion title="Archive selected" icon="archive">
    Archives the checked rows and clears your selection after the list refreshes. Use this for precise, row-by-row cleanup when you want control over which items you dismiss.
  </Accordion>

  <Accordion title="Archive All" icon="archive-x">
    Archives every unarchived failed-delivery row for the forwarder, regardless of which date filter is currently shown on screen. Use this only when you are certain that no remaining items need delivery.
  </Accordion>

  <Accordion title="After archiving" icon="eye-off">
    Archived rows are gone from the failed-delivery list and cannot be restored. The original event is still accessible in bucket history if you need to inspect the payload or start a fresh replay from there.
  </Accordion>
</AccordionGroup>

<Warning>
  **Archive All** is scoped to the entire forwarder, not just the rows matching your current date filter. Use **Archive selected** for precise cleanup when you only want to dismiss a subset of items.
</Warning>

## Bulk operations

Both replay and archive support bulk actions so you can work through large queues efficiently.

<Tabs>
  <Tab title="Bulk replay">
    Select up to 100 rows and click **Replay Selected**, or click **Replay All** to target every item matching your current date filter. Repost deduplicates by event ID so the same event is not delivered twice within one job. The rows leave the failed-delivery list once the job completes its source cleanup.
  </Tab>

  <Tab title="Bulk archive">
    Select the rows you want to dismiss and click **Archive**, or use **Archive All** to clear the entire forwarder queue. Archive is immediate and irreversible — rows are removed from the list as soon as you confirm.
  </Tab>
</Tabs>

## Retention

Failed deliveries follow the history retention window for your workspace plan. Items older than your plan's retention period are no longer accessible in the failed-delivery list or in bucket history.

## Recommended triage workflow

<Steps>
  <Step title="Find the failure pattern">
    Inspect several rows before acting. Look for shared status codes, error messages, paths, or function failures that point to a common root cause.
  </Step>

  <Step title="Fix the destination or function">
    Resolve the underlying issue — update your endpoint, fix function code, rotate secrets, or adjust forwarder settings — before replaying a large batch. Replaying into a still-broken destination just creates more failures.
  </Step>

  <Step title="Replay a small sample first">
    Select a handful of rows and run **Replay Selected**. Watch the replay job to confirm delivery succeeds before proceeding.
  </Step>

  <Step title="Replay the remaining set">
    After the sample succeeds, use **Replay All** with the appropriate date filter to redeliver the remaining failed items.
  </Step>

  <Step title="Archive what remains">
    Archive any items that should not be delivered again — for example, events from a provider integration you have since disabled.
  </Step>
</Steps>

## Prevent future failures

Tuning your forwarder settings reduces how often events reach the failed-delivery queue in the first place.

<AccordionGroup>
  <Accordion title="Timeout and retry settings" icon="clock">
    Increase the request timeout if your destination is slow to respond. Adjust retry delays and backoff multipliers to give a struggling destination more recovery time between attempts.
  </Accordion>

  <Accordion title="Circuit breaker" icon="zap-off">
    Enable the circuit breaker to pause delivery automatically when the destination error rate exceeds a threshold. This prevents your retry budget from being consumed while the destination is down.
  </Accordion>

  <Accordion title="Function code" icon="code">
    Review your transform function for unhandled exceptions or incorrect error policies. A function error policy of **Skip** prevents events from reaching failed deliveries if the function itself is the problem.
  </Accordion>

  <Accordion title="Secrets rotation" icon="key">
    If authentication failures are causing retries to exhaust, rotate the relevant secret and update the forwarder configuration before replaying.
  </Accordion>
</AccordionGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="The Failed Deliveries tab is missing" icon="circle-off">
    Failed deliveries are hidden for proxy buckets. Switch to a queued bucket when you need asynchronous retries, transform functions, secrets management, and dead-letter handling.
  </Accordion>

  <Accordion title="Replay All count changed after the job started" icon="refresh-cw">
    Failed-delivery rows can be added, replayed, or archived between the time you click **Replay All** and when the job finishes processing. Date filters are resolved by calendar day before the job source is created. Review the final job counts on the job detail page.
  </Accordion>

  <Accordion title="Archive All removed more rows than expected" icon="archive-x">
    **Archive All** is scoped to the entire forwarder, not just the rows visible under the current date filter. Use **Archive selected** when you need precise control over which items are dismissed.
  </Accordion>

  <Accordion title="Replay buttons are disabled" icon="ban">
    For **Replay Selected**, check that you have selected at least one row. For **Replay All**, confirm the filtered list has at least one item. If a replay job is already active for the forwarder — including a paused one — wait for it to finish or cancel it before starting a new job.
  </Accordion>
</AccordionGroup>