When every PHP worker is busy, the next visitor has to wait. Adding more workers may seem like the obvious fix, but the real cause could be a slow query or a request waiting on another service. Start by finding where the time goes.
Confirm saturation before changing the pool
Worker exhaustion means the available slots are occupied and new work must wait or fail. It is not synonymous with high CPU: slow external calls or database waits can keep workers busy with little execution time.
Record the affected account, incident time, latency and pool status. Compare the queue and active processes with a healthy interval. Restarting can clear counters and remove useful evidence, so capture context first.
Find requests that hold capacity
Use access logs, slow-request evidence and application monitoring to identify repeated expensive routes. Check crawlers, uncached endpoints and background jobs that may produce more concurrent work than the application can sustain.
Keep diagnostic endpoints restricted. Logs can contain customer information or authentication material. Redact samples before sharing and prefer one representative request with a time window over a complete server log export.
Reduce waste before adding workers
Cache suitable responses, move long jobs to supervised queues and bound external-service calls. Test these changes for the application. A queue removes work from the request path; it does not eliminate its memory, CPU or database cost.
Then reassess pool size against memory and dependency capacity. Giving every account more workers can create a simultaneous load the host cannot sustain. Record a rollback point and change one representative workload at a time.
Verify the original workload
Repeat the traffic pattern that produced the incident. Check latency and queue length without ignoring memory or database contention. Compare equivalent time windows and keep the configuration change in the account’s operating record.
EzePanel connects account policy, PHP-FPM and Server Health. Supported recovery actions are conditional and recorded; they do not replace bottleneck investigation. Starting a service again does not prove that the website has recovered.
Put the guide in context
PHP-FPM workflowMonitoringSources and review notes
Checked 17 October 2026. Vendor terms, supported versions and prices can change. Follow the official source before a purchase or server change.
