Why My Laravel Queue Workers Keep Crashing on a VPS: A Step‑by‑Step Fix for PHP‑FPM, Redis Timeouts, and File Permission Nightmares

Ever watched your Laravel queue workers die silently while your production traffic spikes? You’re not alone. I’ve burned countless late‑night hours watching php artisan queue:work exit with “connection refused” or “permission denied” errors, while the end‑user sees delayed emails, missed webhook calls, and angry support tickets. This article cuts through the noise and gives you a concrete, production‑ready roadmap to stabilize queue workers on a VPS.

Why This Matters

Queue workers are the silent backbone of any modern Laravel or WordPress‑powered SaaS. They handle everything from email delivery and image processing to payment reconciliation. When they crash:

• Revenue‑generating jobs are lost.
• Customer trust erodes – “Why didn’t I get my receipt?”
• Server resources balloon as failed jobs retry endlessly.

Fixing the crash isn’t just a convenience; it’s a business imperative.

Common Causes

From my experience on Ubuntu 22.04 VPSes, the top three culprits are:

1. PHP‑FPM misconfiguration – low pm.max_children or aggressive request_terminate_timeout kills long‑running jobs.
2. Redis connection timeouts – default timeout of 0.0 can cause workers to hang, then be killed by supervisor.
3. File permission nightmares – storage and bootstrap/cache not writable by the www-data user.

Step‑by‑Step Fix Tutorial

INFO: All commands assume you have sudo privileges. Adjust paths if your Laravel project lives in /var/www/html instead of /srv/www.

1. Tune PHP‑FPM for Worker Loads

Open the PHP‑FPM pool file for your site (replace www with your pool name):

sudo nano /etc/php/8.2/fpm/pool.d/www.conf

Adjust the following directives:

pm = dynamic
pm.max_children = 50          ; depends on RAM, 1 child ≈ 128MB
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
request_terminate_timeout = 300 ; 5 minutes for long jobs

Save and restart PHP‑FPM:

sudo systemctl restart php8.2-fpm

2. Fix Redis Timeout & Persistence

Open your Redis config (default location on Ubuntu):

sudo nano /etc/redis/redis.conf

Set a realistic timeout and enable stop-writes-on-bgsave-error to avoid silent data loss:

timeout 5
stop-writes-on-bgsave-error yes
save 900 1
save 300 10
save 60 10000

Restart Redis:

sudo systemctl restart redis-server

3. Align File Permissions

Make sure the web user (www-data on Ubuntu) owns the storage directories:

sudo chown -R www-data:www-data /srv/www/yourapp/storage
sudo chown -R www-data:www-data /srv/www/yourapp/bootstrap/cache
sudo chmod -R 775 /srv/www/yourapp/storage
sudo chmod -R 775 /srv/www/yourapp/bootstrap/cache

For shared hosting you may need to use chmod 755 instead, but keep the owner consistent.

4. Configure Supervisor Properly

Supervisor keeps your workers alive. Create /etc/supervisor/conf.d/laravel-queue.conf:

[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=php /srv/www/yourapp/artisan queue:work redis --sleep=3 --tries=3 --timeout=300
autostart=true
autorestart=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/srv/www/yourapp/storage/logs/worker.log
stopwaitsecs=360

Reload supervisor and start the program:

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

5. Verify with a Test Job

Create a quick Laravel job that sleeps for 2 minutes:

php artisan make:job SleepJob

Edit app/Jobs/SleepJob.php:

public function handle()
{
    sleep(120); // simulate long task
    \Log::info('SleepJob completed at '.now());
}

Dispatch it from tinker:

php artisan tinker
>>> dispatch(new \App\Jobs\SleepJob);

Watch the worker.log – you should see a successful completion after 2 minutes, with no supervisor restart.

TIP: Keep numprocs in sync with pm.max_children. If you allocate 50 PHP‑FPM children, you can safely run 30–40 queue workers without starving web requests.

VPS or Shared Hosting Optimization Tips

• Swap Space: Allocate at least 2 GB swap on low‑memory VPSes to avoid OOM kills.
• Ulimit: Increase open files limit for www-data:

  sudo vim /etc/security/limits.conf
  www-data   soft   nofile   65535
  www-data   hard   nofile   65535
  

• Nginx FastCGI buffers: Add to your server block:

  fastcgi_buffers 8 16k;
  fastcgi_buffer_size 32k;
  

• CPU Affinity: Pin heavy workers to specific cores (advanced).

Real World Production Example

Acme SaaS runs a 12‑core DigitalOcean droplet with 32 GB RAM. Before the fix:

• Queue workers crashed every 5 minutes.
• Redis hit 100% CPU, causing “Connection refused”.
• Daily revenue loss of $1,200.

After applying the steps above:

• Zero worker restarts over a 30‑day period.
• Redis CPU dropped from 100% to 15%.
• Revenue increased by 8% thanks to reliable email & webhook delivery.

Before vs After Results

Metric	Before	After
Worker Crashes / Day	12	0
Redis CPU	98%	14%
Avg Job Latency	45 s	6 s

Security Considerations

While fixing crashes, don’t open a back‑door:

• Never set chmod 777 on storage – use 775 with proper owner.
• Restrict Redis to localhost or use a strong password in .env:

  REDIS_HOST=127.0.0.1
  REDIS_PASSWORD=yourStrongPassword
  

• Enable SELinux/AppArmor profiles if your VPS supports them.

WARNING: Disabling request_terminate_timeout (setting it to 0) can let rogue jobs hog PHP‑FPM forever, leading to DoS conditions.

Bonus Performance Tips

• Batch Jobs: Use chunk() or cursor() to avoid loading thousands of rows.
• Database Indexes: Ensure jobs table has an index on reserved_at and available_at.
• Cache Warm‑up: Pre‑populate Redis with config data during deployment.
• Composer Optimizations:

  composer install --optimize-autoloader --no-dev
  php artisan config:cache
  php artisan route:cache
  

• Zero‑Downtime Deploy: Use php-fpm --reload and Supervisor restart after a new release.

FAQ

Q: My queue still dies after these steps. What else can I check?
A: Look at syslog for OOM killer entries, verify ulimit -n, and ensure your swap isn’t disabled.

Q: Can I run Laravel queues on the same server as a WordPress site?
A: Yes, but isolate PHP‑FPM pools (different listen sockets) and give each app its own supervisor program block.

Final Thoughts

Queue worker crashes are rarely a “Laravel bug.” They almost always stem from server‑level mis‑configurations – PHP‑FPM limits, Redis timeouts, or stray permission settings. By tightening those three pillars, you give your jobs the runway they need to finish, your users the reliability they demand, and your bottom line a healthy boost.

Take the checklist, apply it to your next deployment, and watch those crashes disappear like magic.

SUCCESS: Follow the steps above and you’ll see a measurable drop in worker restarts, lower Redis CPU, and faster job throughput—all without extra cost.

Monetize Your New Speed

Now that your app runs like a well‑oiled machine, consider offering premium API tiers or faster webhook processing as a value‑added service. The reliability you just built is a perfect upsell hook for existing customers.

Need a cheap, secure VPS that won’t break the bank while you scale? Check out Hostinger’s affordable plans. They come with one‑click Laravel and WordPress installers, built‑in firewall, and 24/7 support – exactly what a production‑grade dev team needs.