Monitoring Laravel queues and failed jobs in production

Queued jobs are where Laravel apps fail quietly. A controller throws and someone sees a 500; a job throws and it lands in failed_jobs where nobody is looking. Emails never send, webhooks never fire, exports never finish — and the first you hear of it is a confused customer. Laravel queue monitoring closes that gap: it tells you when jobs fail, when the backlog is growing, and when a worker has quietly died. This post covers what to watch and how to get alerted before the silence becomes a support ticket.

The three ways queues fail silently

Queues do not fail in one dramatic way. They fail in three quiet ones:

• Failed jobs — an exception sends the job to failed_jobs after its retries are exhausted. No HTTP response, no user sees it.
• Backlog growth — jobs arrive faster than workers process them. Nothing has "failed," but everything is late.
• Dead workers — the worker process crashed or was never restarted after a deploy. Jobs queue up against a worker that is not there.

Each is invisible from the outside until something downstream breaks.

Make failed jobs loud

By default a failed job is a row in a table. Turn it into a signal. Laravel jobs have a failed() hook that runs when retries are exhausted:

public function failed(\Throwable $e): void
{
    Log::error('Job failed permanently', [
        'job' => static::class,
        'exception' => $e->getMessage(),
    ]);
}

Reporting the exception there means a permanent failure shows up next to your other errors, grouped by type, instead of decaying in a table. With Lookout installed, those reports are grouped by fingerprint, so a thousand identical failures become one issue with a count — not a thousand rows to scroll.

Watch the backlog, not just the failures

A queue can be 100% "healthy" and still ruining someone's day if jobs sit for twenty minutes. Track two numbers:

• Pending jobs — how many are waiting
• Wait time — how long the oldest job has been waiting

A backlog that grows steadily means you are under-provisioned or a job type is slow. Catching the trend early lets you add workers or fix the slow job before SLAs slip.

Get visibility with one install

You should not be tailing php artisan queue:work output to know your queues are healthy. Send the data somewhere you can see it. Install is two commands:

composer require lookout/tracing
php artisan lookout:install

LOOKOUT_LARAVEL=true
LOOKOUT_API_KEY=your-project-api-key
LOOKOUT_URL=https://your-lookout-host.example.com

From there, job failures flow in as grouped issues, and you can see job activity in one place over plain HTTP — no agent to babysit. Because ingest is just JSON, the same dashboard covers your web app, your workers, and any other service you run.

Alert on the right thing

Visibility without alerting just means you find out faster if you happen to look. Set thresholds so the queue tells you:

• Failed jobs cross a count over a 1h window
• A specific critical job (say, billing) fails even once

Route alerts to Email or Slack and lean on grouping so a burst of identical failures pages someone once, not per job. That is the whole point — signal, not noise.

Don't forget the workers themselves

Finally, confirm the workers are actually running. After every deploy, a process manager (Supervisor, Horizon, systemd) should restart them; a missed restart is the classic "queue stopped after the release" bug. Pair process supervision with the monitoring above and you cover all three failure modes: dead workers, growing backlogs, and silent failures.

Laravel's queue is one of its best features — and one of its easiest to neglect. Lookout's free Starter tier (10,000 events a month, one project, no credit card) is enough to wire up failure reporting and alerts on a real app today. Start monitoring your queues for free and let a broken job page you, not your customers.