Dead Letter Queues and Retries

By Kokil Thapa | Last reviewed: September 2026

Background jobs fail. Networks time out, payment gateways return 503, and third-party APIs change without warning. Without Dead Letter Queues and Retries, one bad message can block a worker, flood logs, or silently drop work your business depends on. On production Laravel applications I maintain, queue reliability is not optional—it protects bookings, document uploads, and payment callbacks. This guide explains how dead letter queues and retry policies fit together, with copy-paste patterns for Laravel queues with Redis in 2026.

What are Dead Letter Queues and Retries in a message pipeline?

A retry policy decides how many times a consumer re-attempts a failed job. A dead letter queue (DLQ) is the final destination for messages that exhaust those attempts. Think of retries as automatic recovery and the DLQ as a controlled parking lot—not a graveyard you forget about.

In message brokers like RabbitMQ and Amazon SQS, DLQs are first-class features. In Laravel, you typically combine the failed_jobs table, dedicated queue names, and Laravel Horizon to achieve the same outcome. The mental model stays identical regardless of broker.

The pipeline has four actors you must design explicitly:

• Producer — your app dispatches work with enough context to replay safely.
• Main queue — holds pending jobs; in Laravel this is often a Redis list on Laravel queues and jobs.
• Worker — executes the handler; throws on failure to trigger retry logic.
• DLQ — stores poison messages separately so healthy traffic keeps moving.

A poison message is one that will never succeed—bad JSON, unknown tenant ID, or a permanent 404 from an API. Retrying it ten times wastes CPU and delays legitimate jobs. That is exactly what Dead Letter Queues and Retries prevent when configured correctly.

How do you configure retries and a dead letter queue in Laravel?

Laravel 12 and 13 expose retry controls directly on job classes. PHP 8.3 or higher is required for Laravel 13; Laravel 12 runs on PHP 8.2+. Redis 8.10 remains a solid queue backend for production. The official Laravel queue documentation covers the primitives; the patterns below add an explicit DLQ layer.

Set tries, timeout, and backoff on the job

<?php

namespace App\Jobs;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use Throwable;

class SendBookingConfirmation implements ShouldQueue
{
    use Queueable;

    public int $tries = 5;

    public int $timeout = 120;

    public function backoff(): array
    {
        return [30, 60, 120, 300, 600];
    }

    public function handle(): void
    {
        /* call SMS gateway, send mail, etc. */
    }

    public function failed(Throwable $exception): void
    {
        /* optional: alert ops, log context */
    }
}

The $tries property caps automatic retries. The backoff() method returns seconds between attempts—prefer this over fixed delays for third-party APIs that rate-limit aggressively. See our guide on third-party API integration retry and backoff for related HTTP patterns.

Route exhausted jobs to a dedicated DLQ queue

Laravel does not ship a broker-style DLQ name out of the box. You implement one by re-dispatching failed payloads to a separate queue connection or name after max attempts.

public function failed(Throwable $exception): void
{
    DeadLetterJob::dispatch([
        'original_job' => static::class,
        'payload'      => $this->serializePayload(),
        'exception'    => $exception->getMessage(),
        'failed_at'    => now()->toIso8601String(),
    ])->onQueue('dead-letter');
}

Configure the dead-letter queue in config/queue.php with its own Redis list. No worker should consume it automatically unless you are ready to replay. On booking systems like Adventure Third Pole Trek, I keep DLQ workers stopped by default and replay manually after inspection.

Enable the failed_jobs table as a secondary audit trail

php artisan queue:failed-table
php artisan migrate

Set QUEUE_FAILED_DRIVER=database-uuids in .env. Horizon surfaces these records in its dashboard. The DLQ queue holds actionable copies; failed_jobs holds forensic detail. Use both—they serve different operators.

What retry strategy should you use for failed queue jobs?

Not every failure deserves the same policy. Classify errors first, then map them to retry behaviour. This mirrors how I design API development workflows for client integrations.

Exponential backoff with jitter is the default I recommend. Without jitter, thousands of workers retry simultaneously and create a retry storm. Add randomness between zero and ten seconds on each delay.

Make jobs idempotent before you rely on retries

Retries imply at-least-once delivery. A job may run twice. Store an idempotency key in MySQL 9.7 or PostgreSQL 18 before performing irreversible side effects.

public function handle(): void
{
    $key = 'booking-notify:' . $this->bookingId;

    if (Cache::add($key, true, now()->addDay())) {
        $this->smsGateway->send($this->phone, $this->message);
    }
}

On a legal-tech portal with document notifications, duplicate SMS messages erode client trust fast. Idempotency is cheaper than apologising later.

Use release() for soft failures inside the handler

public function handle(): void
{
    if ($this->gateway->isInMaintenanceWindow()) {
        $this->release(600);
        return;
    }

    $this->gateway->charge($this->orderId);
}

release() requeues without counting as a full failure in some configurations. Prefer explicit $tries limits so release loops cannot run forever. Combine with Horizon metrics from our Laravel queue scaling guide.

When should a failed job go to the dead letter queue instead of retrying?

Send a message to the DLQ when continuing to retry would harm the system or when the error is permanent. The decision tree is simple in practice.

1. If the error is deterministic (validation, 404, unknown SKU), fail fast—one attempt, straight to DLQ.
2. If the error is transient but persists beyond $tries, move to DLQ automatically.
3. If replay could double-charge or double-notify, block auto-replay until idempotency is verified.
4. If the failure indicates a code bug (TypeError, null pointer), alert engineering and DLQ—do not retry in production.

Payment callbacks on eCommerce projects are a common edge case. A malformed callback signature should never retry blindly. Log it, DLQ it, and fix the integration. For operational queues on Quick And Easy Nepalese Grocery, order-fulfilment jobs get five tries; signature failures get one.

Compare this with cron-based processing. Scheduled tasks that fail often restart on the next cron tick without a DLQ concept. Read Laravel cron vs queue worker to pick the right tool before layering DLQ logic.

How do you monitor and replay dead letter queue messages safely?

A DLQ you never inspect is just delayed data loss. Monitoring and replay are half the value of Dead Letter Queues and Retries.

Monitor queue depth and failure rate

With Horizon, watch failed-job counts and queue wait times. Alert when the dead-letter queue depth exceeds a threshold—five messages might be normal after an API outage; five hundred is not.

# Inspect failed jobs
php artisan queue:failed

# Retry one job by UUID
php artisan queue:retry a1b2c3d4-e5f6-7890-abcd-ef1234567890

# Retry all failed jobs (use carefully)
php artisan queue:retry all

For Redis list inspection, the Redis list documentation explains how pending entries are stored. Avoid manual LREM edits unless you know the exact payload format.

Build a controlled replay command

Blind queue:retry all after an outage can replay poison messages too. I prefer an Artisan command that replays DLQ entries one at a time with a dry-run flag.

php artisan dlq:replay --id=42 --dry-run
php artisan dlq:replay --id=42

Log who replayed what and when. On client portals like Mijar Law Associates, audit trails matter as much as delivery. Parse payloads with a JSON formatter during inspection to catch malformed data before replay.

Alert humans on failed()

public function failed(Throwable $exception): void
{
    Log::error('Job dead-lettered', [
        'job'   => static::class,
        'id'    => $this->bookingId ?? null,
        'error' => $exception->getMessage(),
    ]);

    /* Slack, email, or PagerDuty notification */
}

Pair alerts with runbooks. Operators should know whether to replay, patch data, or escalate to development. That is where support and maintenance contracts earn their keep.

How do broker-native DLQs compare to Laravel's approach?

If you integrate with RabbitMQ or Amazon SQS alongside Laravel, know how broker DLQs differ from application-level ones. RabbitMQ uses a dead letter exchange to reroute expired or rejected messages. SQS attaches a redrive policy with maxReceiveCount.

Laravel's strength is developer ergonomics—job classes, Horizon, and Eloquent side effects in one codebase. Broker DLQs shine when polyglot consumers share one infrastructure layer. Many teams run Laravel workers on Redis for app jobs and SQS for cross-service events. Both need the same retry classification discipline.

Deploy workers with Supervisor or Horizon as described in Horizon vs Supervisor. After deploy, reload PHP-FPM so opcache picks up job class changes. Stale code plus replay equals duplicated bugs—I have seen that on shared EC2 deploy pipelines maintained via Linux system administration practices.

For enterprise systems needing guaranteed delivery across services, combine DLQs with outbox patterns and documented replay contracts. That is standard work in enterprise application development engagements where failure has financial or legal consequences.

Rate limiting at the HTTP edge complements queue retries. If your API returns 429 because abuse prevention triggers, queue retries will not help until the limit resets. Review API rate limiting and abuse prevention alongside your DLQ runbooks.

Key Takeaways

• Dead Letter Queues and Retries are complementary: retries recover transient faults; DLQs isolate poison messages so workers keep processing healthy jobs.
• Configure $tries, backoff(), and a dedicated dead-letter queue in Laravel; keep failed_jobs as your audit trail.
• Classify errors before retrying—never auto-retry 400-class client errors or code exceptions.
• Design every retried job to be idempotent; at-least-once delivery is the default, not the exception.
• Monitor DLQ depth, alert on failed(), and replay through a dry-run command with operator audit logs.
• Broker-native DLQs (RabbitMQ, SQS) and Laravel application DLQs share the same operational playbook—inspect, fix root cause, then replay.

People Also Ask

What is the difference between a dead letter queue and a failed jobs table?

A failed jobs table stores serialized job metadata for debugging and CLI retry. A dead letter queue is a separate queue holding messages deliberately removed from the main processing path. In Laravel you often use both: the DLQ for operational isolation and failed_jobs for forensic detail and Horizon integration.

How many retries should a queue job have?

Three to five retries with exponential backoff suits most third-party API calls. Payment and notification jobs need fewer retries plus strict idempotency. Jobs that touch local database state alone can sometimes tolerate more attempts if failures are purely transient infrastructure errors.

Can dead letter queue messages be automatically reprocessed?

Technically yes, but automatic reprocessing without inspection is risky. Scheduled replay works only after the root cause is fixed—API restored, credentials rotated, or bad data corrected. Prefer manual or semi-manual replay with dry-run validation for anything that charges money or notifies customers.

Does Laravel Horizon include a dead letter queue?

Horizon monitors failed jobs and queue metrics but does not create a broker-style DLQ automatically. You implement DLQ behaviour by routing exhausted jobs to a named queue in failed() and controlling whether workers consume that queue. Horizon then displays the backlog like any other queue.

Ship reliable background processing with Dead Letter Queues and Retries

Dead Letter Queues and Retries turn queue failures from silent emergencies into manageable operations. Start with explicit try limits, exponential backoff, idempotent handlers, and a dedicated DLQ queue. Add monitoring before you need it—not after a payment gateway outage drops a day's worth of orders.

If you want help designing queue architecture for a Laravel application, payment integration, or high-traffic eCommerce workflow, contact us or explore custom software development and web development services. Reliable background jobs are infrastructure, not an afterthought—and getting Dead Letter Queues and Retries right pays for itself the first time production stays up while you fix one bad message.