Dead Letter Queue

A quarantine queue for jobs that kept failing, so good work can continue while operators inspect and safely replay the bad ones.

where failed jobs goqueue for poison messagesholding area for broken eventsstop retrying this message foreverfailed message bucketwhere do I look at the jobs that never randead leter queuejobs that failed too many times

See it

Live demo coming soon

What it is

A dead letter queue is a separate holding area for messages or jobs that could not be processed after the allowed attempts. Moving them aside lets healthy work continue while preserving the failed payload and error context for inspection. The name borrows from the postal service's dead letter office, where undeliverable mail waits instead of being thrown away. Amazon SQS calls the move configuration a RedrivePolicy.

Reach for one after retries have a clear limit and transient failures use backoff. Alert when messages arrive, group failures by cause, fix the consumer or data, then replay through a controlled path. A dead letter queue is an operational workflow, not a trash can.

Gotcha: automatic replay can create the same failure storm again, and a poison message may still fail after the code is fixed. Preserve the original message ID for idempotency, restrict access because payloads may contain sensitive data, set a deliberate retention period, and never silently purge failures that nobody examined.

Ask AI for it

Add an Amazon SQS dead-letter queue to this worker using RedrivePolicy with deadLetterTargetArn and maxReceiveCount=5. Set the dead-letter queue retention longer than the source queue, emit a CloudWatch alarm for ApproximateNumberOfMessagesVisible, store the original message ID for idempotent processing, and build a rate-limited replay command that supports dry run and preserves message attributes. Provide Terraform, worker changes, and tests for retry exhaustion, alerting, and replay.

You might have meant

message queueworkeridempotency keyevent driven architectureexponential backoff