Ask Claude to Implement a Dead Letter Queue for Failed Jobs
Jobs fail. The question is whether your system quietly discards them or gives you a fighting chance to inspect, replay, or alert on them. A Dead Letter Queue (DLQ) is the pattern that answers that — and Claude can add one to any queue-based system.
Add a Dead Letter Queue to our BullMQ setup. After 3 failed attempts, move jobs to a 'failed-jobs' queue. Write a worker that processes the DLQ by logging the job data and error to our Sentry instance, and add a /admin/dlq endpoint that lists failed jobs with their error messages and lets us manually requeue them.
Claude will configure the BullMQ retry and backoff settings, create the DLQ worker with your Sentry integration, and build the admin endpoint with basic auth protection. It understands that the requeue logic needs to copy job data rather than move a reference, so replayed jobs start fresh.
The same pattern applies to other queue backends:
# For SQS
Add a DLQ to our SQS queue with a maxReceiveCount of 5. Write a Lambda that polls the DLQ and posts a Slack alert with the message body and error attributes.
# For Redis Streams
Set up a consumer group with XAUTOCLAIM to move stale messages into a dead letter stream after 3 delivery attempts.
Tell Claude what visibility you need — just logging, alerting, or a full replay UI — and it'll scope the implementation accordingly.
Silent job failures are invisible bugs; a DLQ turns them into actionable signals.
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.