Why Laravel Queue Workers Stop — Common Causes and Fixes
Laravel queue workers can quietly stop processing jobs in production. Here's how to spot the common causes — memory limits, restarts, lost DB connections — and fix them.
Laravel queue workers are usually quiet — until they stop. The tricky part is that a stopped worker often does not fail loudly. The queue simply stops moving while jobs pile up. After running queues across several production systems, here are the causes I keep running into and how I fix them.
Memory limits and the --memory flag
The Laravel queue worker has a built-in memory check. When it exceeds the configured limit, the worker exits cleanly so the supervisor can restart it. The default is 128 MB, which is fine for most jobs but tight if you process imports, exports, or anything that loads many records into memory.
If your jobs handle batch work, set --memory=512 (or higher) when starting the worker. Without that, you will see workers cycling far more often than expected, and stuck jobs will appear during the gap between exit and restart.
Lost database connections
Long-running workers can lose their MySQL or Postgres connection — especially if your database has a wait_timeout that closes idle connections. The worker stays running but every job fails with a "MySQL server has gone away" error.
Use --max-jobs or --max-time so the worker recycles before any connection times out. I usually pair --max-jobs=1000 with a small --tries value so transient failures are retried but stale connections do not accumulate.
The supervisor is not actually running
This sounds obvious but I see it constantly. After a deploy or server restart, supervisord can fail silently. The worker exits gracefully on artisan queue:restart, but nothing brings it back.
Always have a healthcheck. A cron that checks pgrep queue:work and alerts on failure has saved me more than once. For larger systems, Laravel Horizon's monitoring covers this cleanly.
Failed jobs going unprocessed
When a job throws more exceptions than --tries allows, it lands in the failed_jobs table. If you are not actively reviewing that table or running queue:retry, those jobs simply sit. The worker is fine. The work is not getting done.
Most queue worker problems are not bugs in Laravel — they are operational. Set the right flags, watch failed_jobs, and have a healthcheck on your supervisor. With those in place, queues become genuinely boring, which is exactly what you want.
About the author

Richard Gamora
Fullstack developer based in the Philippines, working mostly with Laravel and Vue.js, with eight years of production experience across web and mobile.
More on Laravel
April 15, 2026
Laravel N+1 Query Problem: How to Spot and Solve It
The N+1 query problem is the most common performance issue in Laravel apps. Here's how to detect it with the query log, fix it with eager loading, and prevent it from coming back.
April 8, 2026
Laravel API Resources vs Fractal — Which Should You Use
Laravel API Resources and Fractal both transform models into JSON. Here's how they compare on flexibility, includes, performance, and team ergonomics.
April 1, 2026
Running Laravel Migrations in Production Without Downtime
Production database migrations need care — locked tables, long ALTERs, and mismatched code can cause outages. Here's a practical playbook for safe Laravel migrations.