What is a dead-letter queue (DLQ)?
A DLQ (dead-letter queue) is a holding area for messages that couldn't be processed successfully — events that exhausted their retry budget, hit a terminal error, or got stuck in a way retries can't fix. Without a DLQ, those events disappear silently or block the rest of the queue.
What ends up in a DLQ
Three categories of failure:
- Exhausted retries. A delivery has been attempted N times and still fails. After N, the system moves it to the DLQ instead of looping forever.
- Terminal destination responses. A destination keeps returning non-2xx or timing out until the retry budget is exhausted.
- Poison messages. A specific event triggers a bug that crashes or rejects the consumer every time. Without a DLQ, the queue stays stuck on this one event.
Provider signature failures are different: Hooksbase rejects forged or stale provider requests before persistence, so they do not create deliveries or DLQ entries.
Recovery patterns
Four patterns show up in production:
- Manual inspect-and-replay — engineer opens the DLQ, looks at an entry, decides to replay
- Bulk re-drive after a fix — ship a fix, then bulk-replay everything that failed for the same reason
- Escalation path — high-stakes failures notify on-call immediately
- Backfill from source — for events past the payload retention window, query the upstream API
Hooksbase moves terminally-failed deliveries to a DLQ tier with their own dashboard, querying, and re-drive operations. For the practical recovery walkthrough: Recover failed agent events with DLQ and replay. For the design framework: Webhook DLQs: design and recovery patterns.
Frequently asked questions
What ends up in a dead-letter queue?
Three kinds of failure: deliveries that exhausted their retry budget, destinations that returned terminal errors or timed out until the budget ran out, and poison messages that reject or crash the consumer every time. Provider signature failures are different — Hooksbase rejects forged or stale requests before persistence, so they never create a DLQ entry.
How do you recover events from a DLQ?
Four patterns: inspect and replay a single entry by hand, bulk re-drive everything that failed for the same reason once a fix has shipped, escalate high-stakes failures to on-call immediately, and backfill from the source system for events past the payload retention window.
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
- Retry
Re-attempting a failed delivery on a backoff schedule until it succeeds or hits a retry budget.
Read - Replay
Re-running a retained event with the same input — typically after fixing a bug that caused the original to fail.
Read - Observability
Knowing what arrived, what was attempted, what succeeded, and what failed — without grepping logs.
Read - Email ingest
Accepting an inbound email as an event by sending it to a webhook’s generated ingest address.
Read