Skip to main content
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.
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.

​
What sends an event to failed deliveries

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

Retries exhausted

The destination returned connection failures, 408, 429, or 5xx responses on every attempt until the forwarder reached its configured maximum retry count.

Function error policy

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.

One event, one forwarder

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.

​
Inspect a failed delivery

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

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

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

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

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

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.

​
What the detail view contains

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

Replay Selected

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.

Replay All

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.
Watch the replay job page for real-time success, failure, pending, and rate counts while a failed-delivery replay is running.
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.

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

​
Bulk operations

Both replay and archive support bulk actions so you can work through large queues efficiently.
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.

​
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.
1

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

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

Replay a small sample first

Select a handful of rows and run Replay Selected. Watch the replay job to confirm delivery succeeds before proceeding.
4

Replay the remaining set

After the sample succeeds, use Replay All with the appropriate date filter to redeliver the remaining failed items.
5

Archive what remains

Archive any items that should not be delivered again — for example, events from a provider integration you have since disabled.

​
Prevent future failures

Tuning your forwarder settings reduces how often events reach the failed-delivery queue in the first place.
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.
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.
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.
If authentication failures are causing retries to exhaust, rotate the relevant secret and update the forwarder configuration before replaying.

​
Troubleshooting

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