What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Laravel queue worker stopping in Docker does not, by itself, prove that Docker killed it. Laravel can exit a worker after a timeout, a restart signal, a memory limit, or an intentional recycle; Docker can also force a container to stop if it exceeds its shutdown grace period. Start by identifying which process ended, then compare the relevant time limits and lifecycle settings.
First, find out what actually stopped
Distinguish a worker-process exit from a container exit before changing configuration. Inspect the container’s state and exit status, orchestrator events, and worker output. If the worker process ended but the container stayed running, investigate Laravel’s worker settings and process supervision. If the container stopped, check its stop events and whether it had time to exit gracefully.
There is no single log line or exit status that proves every case. The evidence from your deployment—worker logs, container state, and orchestrator events—is needed to identify the cause.
Compare the time limits that govern a job
A long-running job can be subject to several independent clocks. They belong to different layers and do different things; changing one does not automatically change the others.
#1 Best Overall
| Limit | What it controls | What to check |
|---|---|---|
| Job-level timeout | Maximum time allowed for a particular job; it takes precedence over the worker’s command-line timeout. | Check the job’s timeout setting as well as the worker command. |
Worker --timeout |
How long a Laravel worker may run a job before the worker exits with an error. | Laravel 13.x documents a default of 60 seconds. Confirm the effective value in your deployment rather than assuming the default applies. |
| Queue retry window | When a job may become eligible for another attempt after being reserved. | For connections using retry_after, keep the job or worker timeout several seconds shorter. For Amazon SQS, the corresponding concept is the queue’s visibility timeout. |
| Network-client timeout | How long a socket or outgoing HTTP request is allowed to wait. | Set connection and request timeouts in the relevant client library; Laravel’s worker timeout may not stop blocked network I/O. |
| Container stop grace period | How long Docker waits for a container to exit after sending its stop signal. | Allow enough time for the current job and shutdown path to finish, or Docker may force termination. |
Keep the retry window longer than the worker timeout
For queue connections configured with retry_after, Laravel recommends that the worker timeout be several seconds shorter than that value. The timeout terminates a worker; retry_after governs when a reserved job may become eligible for retry. If the retry window expires while the original execution is still active, another attempt can overlap it. That can result in duplicate processing, depending on the queue driver, acknowledgement or release timing, and where termination occurs.
Do not treat the two settings as interchangeable. If you use SQS, check the visibility timeout rather than looking for a retry_after setting.
Rank #2
Give network operations their own deadlines
Laravel notes that blocking sockets and outgoing HTTP requests may not respect the worker timeout. Configure the network client’s connection timeout and request timeout so an unreachable service or stalled response cannot leave a job waiting indefinitely. Laravel’s timeout mechanism also requires PHP’s PCNTL extension; verify that it is installed before relying on --timeout to enforce a job deadline.
Recommended Free Tools
Check whether Laravel exited the worker intentionally
A worker can stop without Docker crashing the container. Laravel documents several worker lifecycle controls and exit paths:
Rank #3
--timeoutexits the worker with an error when a job exceeds its allowed runtime.queue:restartasks workers to exit after their current job, commonly as part of a deployment.--stop-when-emptyexits after the queue drains.--max-timeand--max-jobsrecycle workers after a configured time or number of jobs.--memoryexits a worker after it reaches its configured memory limit; Laravel documents a default of 128 MB.
These are distinct from an external container kill. Memory is not a time limit, and a worker that exits because it reached a configured limit is not necessarily evidence of a Docker failure. Laravel also advises releasing heavy resources after jobs to help control resource use in long-running workers.
Make worker exits recoverable
Some Laravel worker exits are expected: workers may be recycled or told to stop after completing a job. A long-running worker therefore needs a process monitor or equivalent restart policy to bring it back when it exits. Check that your supervision setup is monitoring the worker process and restarting it as intended; a container can remain alive even when its worker has exited.
During shutdown, Laravel workers can receive SIGQUIT, SIGTERM, or SIGINT and finish the current job before exiting. Docker sends SIGTERM by default unless the image or container specifies a different stop signal. If the container has not exited before its configured stop timeout, Docker sends SIGKILL, which does not allow the worker to finish its graceful shutdown path.
Align the container’s grace period with the maximum expected job duration and the time needed for shutdown. Docker documents defaults of 10 seconds for Linux containers and 30 seconds for Windows containers when no per-container default is configured; deployments can set a different stop timeout. Those defaults may be too short for a worker that needs longer to finish a job.
Best Value
- Docker, Docker Swarm, Docker Compose, Programmer, Developer, Coding, Programming, Software Engineer, Code, DevOps, Deploy, Deployment, Kubernetes, Salt, Puppet, Chef, Terraform, Container, AWS, Azure, Cloud, Geek, Funny, Computer, Software, Tech, IT
- Integration, Scrum, Compile, Compilation, Science, Bug, Debug, Python, Linux, Java, Javascript, Scala, Dotnet, Kotlin
- Lightweight, Classic fit, Double-needle sleeve and bottom hem
Use the symptom to choose the next check
- Worker exits around the same elapsed time on long jobs: Compare the job-level timeout with the worker’s
--timeout, and verify PCNTL is available. - A job appears to run twice: Compare the effective job or worker timeout with
retry_after, or with the SQS visibility timeout. Check the actual job acknowledgement and retry behavior before concluding that a timeout caused the duplicate. - A job stalls during an HTTP call or socket operation: Inspect the client’s connection and request timeout settings, not only Laravel’s worker timeout.
- The worker exits but the container remains up: Look for Laravel lifecycle settings and confirm that a process monitor restarts the worker.
- The container stops during deployment or shutdown: Check the stop signal, container grace period, and orchestrator events. Determine whether Laravel had enough time to finish the current job before Docker’s forced-kill deadline.
- Workers stop after heavy jobs or at a repeatable resource threshold: Check the worker’s memory limit and any configured recycling options separately from elapsed-time settings.
Make retryable work safe
Align the worker timeout with the queue retry or visibility window, and give network operations their own deadlines. Because retries and termination can occur at different points, make jobs that cause external side effects safe to retry—for example, by using an idempotent operation or a deduplication mechanism suited to the application. The correct behavior depends on the queue driver and where execution stops; not every restart loses work, and not every retry creates a duplicate.
Quick Recap
Official references
- Laravel 13.x queue documentation covers worker timeouts, retry timing, worker lifecycle controls, and signals.
- Laravel 13.x queue guide discusses timeout behavior and the PCNTL requirement.
- Docker container restart reference explains container stop timeouts and forced termination.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
