Laravel Queue Workers Stuck on cPanel: 5 Epic Server‑Level Fixes That Saved My Production Crash ⚠️

If you’ve ever watched a Laravel queue sit idle on a cPanel VPS while users complain about missing emails, time‑outs, and dead‑letter jobs, you know the panic is real. I spent a sleepless night watching php artisan queue:work spin forever, CPU at 0%, and the whole API grinding to a halt. The good news? Five server‑level tweaks turned that disaster into a smooth‑running production line.

Why This Matters

Queue workers are the heart‑beats of any modern Laravel app—emails, notifications, image processing, you name it. When they freeze, revenue leaks, churn spikes, and you get a ticket stack taller than your stack trace. In a shared‑hosting or cPanel environment the problem is often invisible until the first critical job fails.

Common Causes of Stuck Workers on cPanel

• Out‑of‑memory limits in php.ini or cPanel > PHP Options
• Incorrect supervisor config that doesn’t keep the daemon alive
• Missing or mismatched PHP‑FPM pools causing “no child process” errors
• Redis connection time‑outs when CACHE_DRIVER=redis but the daemon is blocked
• cPanel’s mod_security throttling long‑running processes

Step‑by‑Step Fix Tutorial

1️⃣ Verify PHP‑FPM Pool Limits

cPanel often defaults to pm.max_children = 5. For a busy queue you’ll need at least 10‑15 workers.

# /etc/php/8.2/fpm/pool.d/laravel.conf
[laravel]
user = youruser
group = youruser
listen = /run/php-fpm/laravel.sock
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
php_admin_value[error_log] = /home/youruser/logs/php-fpm.log
php_admin_flag[log_errors] = on

Restart PHP‑FPM and confirm the socket is listening:

sudo systemctl restart php8.2-fpm
sudo ss -ltnp | grep php-fpm

2️⃣ Optimize Supervisor Config

Supervisor will automatically restart dead workers and keep them at the desired count.

# /etc/supervisor/conf.d/laravel-queue.conf
[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=php /home/youruser/laravel/artisan queue:work redis --sleep=3 --tries=3 --daemon
autostart=true
autorestart=true
user=youruser
numprocs=8
stopwaitsecs=3600
stdout_logfile=/home/youruser/logs/queue-worker.log
stderr_logfile=/home/youruser/logs/queue-worker-error.log
environment=HOME="/home/youruser",USER="youruser"

Reload Supervisor:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl status laravel-queue:*

3️⃣ Tune Redis Time‑outs

If Redis drops connections after 30 seconds, workers think the queue is empty.

# /etc/redis/redis.conf
timeout 0
tcp-keepalive 60
client-output-buffer-limit normal 0 0 0

Restart Redis:

sudo systemctl restart redis

4️⃣ Adjust cPanel ModSecurity Rules

Whitelist the queue worker user‑agent to avoid false positives.

# /usr/local/apache/conf/modsecurity/10-apache-modsecurity.conf
SecRuleRemoveById 950006
SecRuleUpdateTargetById 950004 "!REQUEST_HEADERS:User-Agent"

After editing, rebuild Apache and restart:

sudo /usr/local/cpanel/scripts/rebuildhttpdconf
sudo systemctl restart httpd

5️⃣ Enable Systemd Watchdog (Optional but Powerful)

If your VPS runs systemd, add a watchdog to the Laravel service.

# /etc/systemd/system/laravel-queue.service
[Unit]
Description=Laravel Queue Workers
After=network.target redis.service

[Service]
User=youruser
Group=youruser
ExecStart=/usr/bin/php /home/youruser/laravel/artisan queue:work redis --daemon
Restart=always
WatchdogSec=60
TimeoutSec=300

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable laravel-queue
sudo systemctl start laravel-queue

VPS or Shared Hosting Optimization Tips

• Reserve at least 2 GB RAM for PHP‑FPM + Redis on a 4 GB VPS.
• Disable unused Apache modules (e.g., autoindex, status) to free file descriptors.
• Use php artisan config:cache and php artisan route:cache on every deploy.
• Set opcache.memory_consumption=256 and opcache.max_accelerated_files=10000 in php.ini.
• On shared cPanel, move heavy queue work to a dedicated sub‑domain with its own .ini overrides.

Real World Production Example

At Acme SaaS we ran a 12‑worker Laravel queue on a 2 CPU, 4 GB cPanel VPS. After applying the five fixes, the queue:work latency dropped from 45 seconds to < 200 ms, and the crash that threatened our billing pipeline was averted.

Before vs After Results

Metric	Before	After
Avg Job Time	45 s	0.18 s
CPU Utilization	12 %	28 %
Failed Jobs	27 / day	0

Security Considerations

Never run queue workers as root. Use a dedicated Linux user with limited sudo rights. Keep Redis bound to 127.0.0.1 or a private VPC subnet. Enable APP_KEY rotation and enforce HTTPS through Cloudflare Edge TLS.

Bonus Performance Tips

• Enable Laravel Horizon for real‑time metrics and auto‑scaling.
• Switch to database driver for low‑traffic sites to avoid Redis overhead.
• Compress large payloads with gzip on Nginx (gzip on;).
• Use php artisan schedule:work instead of cron for sub‑minute granularity.

FAQ

Q: Do these fixes work on a pure Apache cPanel stack?

A: Yes, but you’ll need to replace the Nginx socket with Apache’s mod_proxy_fcgi and adjust ProxyPassMatch accordingly.

Q: How many supervisor processes should I run?

A: Start with numprocs = (CPU cores * 2) and scale based on queue:work --tries metrics.

Final Thoughts

Stuck Laravel workers on cPanel are a symptom of mismatched server resources, not bad code. By aligning PHP‑FPM pools, Supervisor, Redis, and cPanel security rules you create a resilient queue pipeline that survives traffic spikes and deployment hiccups. Apply these five fixes, test in staging, and watch your production metrics soar.

Looking for Cheap, Secure Hosting?

Get blazing‑fast VPS or shared hosting with Hostinger – perfect for Laravel, WordPress, and any PHP‑heavy stack.