If your Laravel queue works locally but nothing happens in production, it’s almost always because there’s no worker running. queue:work needs to run continuously, and SSH sessions don’t count.
The correct solution is Supervisor.
Install Supervisor
On Ubuntu:
Bash
sudo apt update
sudo apt install supervisorMake sure it’s running:
Bash
sudo systemctl status supervisorCreate a queue worker config
Create a config file:
Bash
sudo nano /etc/supervisor/conf.d/laravel-queue.confExample config to run on a Redis queue:
INI
[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=/usr/bin/php8.2 /var/www/myapp/artisan queue:work redis --sleep=3 --tries=3 --timeout=90
autostart=true
autorestart=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/myapp/storage/logs/queue.log
stopwaitsecs=3600What matters here:
numprocs= number of workers--triesand--timeoutprotect you from bad jobsstdout_logfileis essential for debugging
Start the workers
Bash
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start laravel-queue:*… and check their status:
Bash
sudo supervisorctl statusLaravel config
In .env
QUEUE_CONNECTION=redis… and if you’re using database queues, don’t forget:
Bash
php artisan queue:table
php artisan migrateRestart workers on deploy
Workers don’t reload code automatically. Always run:
Bash
php artisan queue:restartSkipping this is a classic production bug, and your queue workers won’t be using your deployed codebase.
Common issues
- Jobs stuck → worker not running or wrong queue
- Jobs failing instantly → PHP version mismatch
- No logs → wrong permissions on storage/logs
Once Supervisor is in place, queues stop being fragile and start being boring – which is exactly what you want.
Leave a Reply