Bulk replay (sometimes called "re-drive") is the operation of replaying or DLQ-re-driving many deliveries at once based on a selection — a date range, a destination, an error type, or a status. Available on the Starter tier and above.
The trigger is usually: you shipped a fix, and now want to replay everything that failed for the same reason without clicking each entry individually.
Common bulk-replay scenarios
- Bug deploy caused a wave of 500s. Filter the DLQ for
status_code = 500 AND date > 2026-04-25T14:00, re-drive the matching deliveries. - Destination recovered after an outage. Filter for the affected destination and time window, then re-drive once the same destination can accept traffic again.
- Consumer bug fix recovers stuck events. Filter for the failed status or error code, then replay the same persisted dispatch payload after the consumer is fixed.
- Provider had an outage; events failed during it. Filter by date range and destination, re-drive the affected deliveries.
Replay and DLQ re-drive intentionally use the original resolved destination snapshot and persisted dispatch snapshot. If you need a new destination or a newly edited transform to apply, create fresh deliveries from the source system or a source backfill path instead of replaying old delivery records.
Safety patterns
Bulk operations are powerful and easy to misuse. Three patterns to apply:
- Filter before action. Always preview the selection in the dashboard before triggering re-drive — what looks like 50 events can be 50,000 if the filter is wrong.
- Make sure handlers are idempotent. Bulk replay creates duplicates from the consumer's perspective; if the consumer doesn't dedupe, you'll cause double-processing at scale.
- Respect the destination's capacity. Bulk jobs process items in chunks and still obey webhook throttling and replay quotas, but your filter should stay within what the destination can safely handle.
For the practical recovery walkthrough: Recover failed agent events with DLQ and replay.
Related terms
- Replay
Re-running a retained event with the same input — typically after fixing a bug that caused the original to fail.
Read - DLQ (Dead-Letter Queue)
A holding area for messages that failed terminally so they can be inspected and recovered.
Read - Idempotency
A property where performing an operation multiple times produces the same result as performing it once.
Read - Attempt
One HTTP request within a delivery's retry chain.
Read