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:
The destination returned connection failures, 408, 429, or 5xx responses on every attempt until the forwarder reached its configured maximum retry count.
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.
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.
Navigate to the forwarder that owns the failed destination. The failed-delivery list is scoped to that forwarder.
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.
Click any row to open the detail view. The detail is built from the latest unarchived failed-delivery record for that event and forwarder.
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.
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#
| 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.
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.
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.
Archive selected
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.
Archive All
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.
After archiving
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.
Recommended triage workflow#
Inspect several rows before acting. Look for shared status codes, error messages, paths, or function failures that point to a common root cause.
Resolve the underlying issue before replaying a large batch: update your endpoint, fix function code, rotate secrets, or adjust forwarder settings. Replaying into a still-broken destination just creates more failures.
Select a handful of rows and run Replay Selected. Watch the replay job to confirm delivery succeeds before proceeding.
After the sample succeeds, use Replay All with the appropriate date filter to redeliver the remaining failed items.
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.
Timeout and retry settings
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.
Circuit breaker
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.
Function 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.
Secrets rotation
If authentication failures are causing retries to exhaust, rotate the relevant secret and update the forwarder configuration before replaying.
Troubleshooting#
The Failed Deliveries tab is missing
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.
Replay All count changed after the job started
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 removed more rows than expected
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.
Replay buttons are disabled
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.