Glossary · Reliability
Dead-letter queue
Also called: DLQ, error queue, failed items queue, error handling
A dead-letter queue is a holding place for messages or items that couldn't be processed after all retries, kept aside with their error so a person can inspect, fix and replay them instead of losing them.
The term comes from message queues: a message that keeps failing is moved to a separate "dead letter" queue so it stops blocking the others. The principle applies to any automation. Some items will fail for reasons retries can't fix: a malformed payload, a deleted record, a permission that was revoked. Those need a place to go that isn't "nowhere".
What a good dead-letter path records
- the original input, exactly as received,
- which step failed and the error it returned,
- when, and how many attempts were made,
- enough context to replay it (the workflow and version).
Designing the flow
- Retry transient failures with exponential backoff.
- When retries are exhausted, or the error is clearly permanent, send the item to the dead-letter path: a sheet, a ticket, a Slack channel, a database table.
- Alert a named owner, not a channel everyone has muted.
- Fix the cause, then replay the item through the same workflow, which is safe if the steps are idempotent (idempotency key).
A dead-letter queue that nobody reviews is just a slower way to lose data. Put a weekly look at it on someone's calendar.
In Fluxo Flow
The Error Handler node catches failures from earlier steps so you can recover or report them: post the failed item and error to Slack, append it to a Google Sheet as a working dead-letter list, or call your own endpoint. Every run keeps a step-by-step trace with inputs, outputs and errors, and you can compare a failed run with a good one side by side.
Read next
Related terms
- Exponential backoffExponential backoff is a retry strategy in which the wait before each new attempt grows exponentially (for example 1, 2, 4, 8 seconds), usually with random jitter, up to a maximum number of attempts or delay.
- Idempotency keyAn idempotency key is a unique value a client sends with a request so that, if the same request is retried, the server recognizes it and returns the original result instead of doing the work a second time.
- Rate limitA rate limit is a cap an API puts on how many requests a client may make in a time window; requests over the limit are refused, usually with HTTP status 429 Too Many Requests.
- Audit logAn audit log is a chronological, tamper-resistant record of who did what in a system and when, kept so that changes, approvals and access can be traced afterwards.
- Dry runA dry run executes a workflow end to end with its side effects simulated, so you can see what every step would do without sending, writing or charging anything.
- Cron expressionA cron expression is a compact five-field string (minute, hour, day of month, month, day of week) that tells a scheduler exactly when to run a job.