How to monitor a Laravel queue worker so it doesn't silently die

A queue worker that has stopped is one of the quietest failures a Laravel app can have. The site loads, forms submit, nothing errors. But the confirmation emails are not going out, the exports never finish, and the webhooks pile up. You usually find out from a customer.

Why workers die

php artisan queue:work is a long-running process, and long-running processes end for ordinary reasons:

• the server ran out of memory and the kernel killed it,
• an uncaught error or a leaked resource brought it down,
• you deployed, and it kept running old code or exited,
• the server rebooted and nothing started it again,
• a single job hung and the worker stopped making progress.

Starting the worker once in a terminal solves none of this. It needs a supervisor.

Run it under a process manager

Laravel's queue documentation recommends a process monitor such as Supervisor so the workers are continually running. On a modern Ubuntu server, systemd does the same job without extra software. Create a unit (adjust the user, the path and the app name):

sudo tee /etc/systemd/system/myapp-queue-worker.service > /dev/null <<'EOF'
[Unit]
Description=myapp queue worker
After=network.target

[Service]
User=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/php artisan queue:work --sleep=3 --tries=3 --max-time=3600
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now myapp-queue-worker

Two details do the heavy lifting:

• Restart=always brings the worker back after a crash or a kill.
• --max-time=3600 makes the worker exit cleanly after an hour, and systemd starts a fresh one. This keeps memory growth in check and means a worker never runs for days on stale state.

Check that it is up:

systemctl status myapp-queue-worker

Restart workers on every deploy

A running worker has your application code loaded in memory. The docs are explicit: when you deploy, you must restart your queue workers so that they use the newly deployed code. Add this to your deploy script:

php artisan queue:restart

It signals the workers to finish their current job and exit gracefully, and systemd starts them again with the new code. Forgetting this step is the classic cause of "it works in the browser but the job still runs the old version".

Alert when something is wrong

Keeping the worker alive is half of it. You also want to know when it is not.

Watch queue size

Laravel ships a command that warns when a queue grows beyond a threshold:

php artisan queue:monitor redis:default --max=100

Schedule it to run every minute, and listen for the event it fires to send yourself a notification. A growing backlog is the clearest sign nothing is consuming jobs.

Watch failed jobs

php artisan queue:failed

A rising count means jobs are running and failing, which is a different problem from a dead worker but just as important.

Check the process itself

The simplest direct test is whether a worker process exists for your app:

pgrep -af "artisan queue:work"

Put that in a cron job or an external check that pings you when it returns nothing.

What PHPGuard checks

If your app uses a real queue driver (anything other than sync), the PHPGuard agent looks for a running queue:work process for that exact app and flags it as critical if the queue is configured but nothing is consuming it. You get an email when it first turns red, so you hear about it before your customers do.

Checklist

• Workers run under systemd or Supervisor, with automatic restart.
• --max-time set, so workers recycle themselves.
• php artisan queue:restart in every deploy.
• Queue size and failed jobs monitored, with an alert.
• Something outside the app checks that a worker process is actually running.