What is bulk replay?
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.
Frequently asked questions
When do you reach for bulk replay?
After shipping a fix, when many deliveries failed for the same reason: a deploy that caused a wave of 500s, a destination that recovered from an outage, a consumer bug that stranded events, or a provider outage over a known window.
What are the safety rules for a bulk re-drive?
Preview the selection before triggering it, because a wrong filter turns 50 events into 50,000. Make sure handlers are idempotent, since bulk replay creates duplicates from the consumer's perspective. And keep the filter inside what the destination can absorb.
What is Hooksbase?
Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.
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 - Code Mode
The JavaScript transform mode inside Hooksbase Automations.
Read