Laravel 대기열이 멈추지 않았을 때 대기열이 진짜 문제가 아니었습니다.

This is a submission for DEV’s Summer Bug Smash: Clear the Lineup powered by Sentry.

The Problem

I had a Laravel application connected to Make.com.

Make.com was sending requests every 30 minutes, and Laravel was processing them through a queue.

Everything worked — until the server restarted.

My first approach was simple:

nohup php artisan queue:work redis &

Enter fullscreen mode Exit fullscreen mode

The worker ran fine, but after a server restart, it was gone.

🔴 1. Why did the queue stop?

Server restart → nohup worker dies → queue stops processing

nohup keeps a process running in the background, but it doesn’t give me a reliable process supervisor.

So I needed the worker to automatically come back.

The First Fix: cPanel Cron + flock

I moved the queue worker startup to a cPanel Cron job.

I also used flock so that Cron wouldn’t create multiple queue workers.

/usr/bin/flock -n storage/framework/queue-worker.lock \
php artisan queue:work redis \
--queue=default --sleep=3 --tries=3 \
--timeout=120 --max-time=120

Enter fullscreen mode Exit fullscreen mode

Now:

• Server restarts → Cron starts the worker again
• Worker already running → flock prevents another worker
• Worker processes jobs → no manual restart

That solved the queue-worker problem.

But then I found another problem.

The Second Problem: Make.com Started Timing Out

The queue was running.

Redis was running.

But Make.com started returning 504 timeout errors.

I initially thought the queue was still the problem.

It wasn’t.

🟠 2. The Hidden Bottleneck

My server had:

65 GB RAM
20 CPU cores

Enter fullscreen mode Exit fullscreen mode

But PHP-FPM was configured with:

pm.max_children = 5
pm.max_requests = 20
pm.process_idle_timeout = 10

Enter fullscreen mode Exit fullscreen mode

That meant only 5 PHP requests could be handled concurrently by that PHP-FPM pool.

So the flow became:

Make.com → Laravel → PHP-FPM → requests wait → timeout

The important discovery was:

The server had plenty of resources. PHP-FPM simply wasn’t configured to use them effectively for the workload.

The Final Fix

I tuned PHP-FPM for the server’s actual capacity and kept the queue worker managed by Cron + flock.

🟢 3. The Final Architecture

cPanel Cron → flock → Laravel Queue Worker → Redis

and

Make.com → Laravel API → PHP-FPM

After the changes:

• ✅ Queue worker automatically starts after restart
• ✅ flock prevents duplicate workers
• ✅ PHP-FPM can handle more concurrent requests
• ✅ Make.com requests stop timing out
• ✅ No more manually restarting everything

What I Learned

The biggest lesson wasn’t about Laravel queues.

It was about looking at the whole request path.

I was initially focused on:

“Why does my queue keep stopping?”

The better question was:

“Where exactly is my system becoming the bottleneck?”

A queue problem isn’t always a queue problem.

Sometimes the real bottleneck is before the queue.

Final Architecture

                 Make.com
                    │
                    ▼
              Laravel API
                    │
                    ▼
                PHP-FPM
             (enough workers)
                    │
                    ▼
                  Redis
                    │
                    ▼
             Queue Worker
                    │
                    ▼
             Processed Jobs

        cPanel Cron + flock
                 │
                 └── keeps worker reliable

Enter fullscreen mode Exit fullscreen mode

The result was a more reliable Laravel + Redis + Make.com workflow without manually restarting everything after a server restart.

Best Use of Sentry

Best Use of Google AI