A PHP worker is a server process that runs your site’s PHP code for one request at a time. Each request that misses the cache needs a free worker.
Your plan’s PHP worker count is the number of uncached requests your site can process at the same moment. When every worker is busy, new requests wait in a queue.
Most brochure sites and blogs need only a few. Stores, membership sites and online courses need more, because most of their logged-in pages can’t be cached.
PHP workers are one of several web hosting plan terms explained for beginners. Other plan limits, such as entry processes and inodes, are covered in Hosting Resource Limits Explained.
How PHP workers work
A PHP worker takes one uncached request, runs WordPress and its plugins, queries the database, sends back the page, and then takes the next request.
On most servers, PHP-FPM manages these workers. The PHP-FPM configuration manual says it pm.max_children setting “sets the limit on the number of simultaneous requests that will be served”.
WP Engine’s PHP worker guide compares workers to cashiers in a store: “each cashier handles one customer at a time.” If all cashiers are busy, a line forms.
Here is what happens to a single visit:
- A visitor requests a page.
- If a cached copy exists, the server sends it, and no worker is used.
- If not, the request waits for a free worker.
- The worker builds the page, then takes the next request.
For your site, this means: worker count limits how many slow, dynamic pages you can serve at once. It doesn’t limit total visitors.
Cached vs uncached traffic
Cached pages skip PHP entirely, so a well-cached site can serve many visitors with a small number of workers.
A page cache stores a finished HTML copy of a page, so the next visitor skips PHP and the database.
The setup is covered in hosting-level caching for speed.
Some requests can’t be cached. They still need a worker every time:
- Logged-in users, including you in wp-admin
- Cart, checkout, and account pages
- Search results and form submissions
- Background AJAX calls and cron jobs
- Bots requesting pages that aren’t in the cache
WooCommerce’s caching guidance says Cart, My Account, and Checkout must be excluded from caching. These pages “need to stay dynamic since they display information specific to the current customer”.
For your site, this means: count your uncached traffic, not your total traffic.
A well-cached blog with heavy traffic may use fewer workers than a small store with 50 shoppers checking out at once.
What needs more PHP workers
Sites with many logged-in users or personalized pages need the most workers, because those requests can’t be served from cache.
- WooCommerce stores: every cart, checkout, and account page runs PHP, which is why WooCommerce hosting plans compared weigh PHP workers alongside CPU and RAM.
- Membership sites: members see pages built for them after they log in.
- Online courses (LMS): lessons, quizzes, and progress tracking are personal.
- Busy admin teams: several editors working in wp-admin at once each use workers.
- Slow plugins: a request that takes 3 seconds holds a worker 3 times longer than one that takes 1 second.
Bots matter too. Any bot that requests an uncached URL holds a worker exactly as a shopper would.
On a new site, bots can send most of the traffic, as the first three days of our Kinsta test account showed.
How hosts state PHP workers
Managed WordPress and cloud hosts often list PHP workers per plan, while most shared hosts don’t publish a worker number. These counts were rechecked on October 4, 2026.
| Plan | PHP workers stated | Source |
|---|---|---|
| WPX Starter (1 site) | 9 | WPX pricing page |
| WPX Business (up to 5 sites) | 15 | WPX pricing page |
| Hostinger Cloud Startup | 100 | Hostinger cloud page and our own account |
The Hostinger Cloud Startup account we bought shows 100 PHP workers alongside 4 CPU cores and 4 GB of RAM. Hostinger’s cloud hosting page lists the same figure.
Two cautions:
- Workers share the server. 100 workers on 4 CPU cores can’t all run at full speed together. CPU and RAM still set the real ceiling.
- Per plan or per site. On a multi-site plan, check whether the count is shared across all sites. WPX’s pricing page lists 15 workers on Business, which allows up to 5 sites.
The WPX managed WordPress review covers what else those plans include.
For your site, this means: treat a worker count as one clue, next to CPU, RAM, and caching. A bigger number alone doesn’t prove a faster site.
How many PHP workers do I need?
You need enough workers to cover your busiest moment of uncached requests, and you can estimate it with simple math.
Workers busy at once ≈ uncached requests per second × average PHP time per request.
Example: your store gets 4 uncached requests a second at peak, and each takes 0.5 seconds. That keeps about 2 workers busy.
Leave headroom for spikes, bots, and admin work, so a plan with several times that number is safer.
Average response time is in your host’s dashboard, a performance plugin, or your logs. Peak traffic is in your analytics.
In our view, a well-cached blog rarely needs more than an entry plan offers. A store, membership, or course site should pick a plan that states its worker count.
Signs you’re short on PHP workers
The clearest signs are 502 and 504 errors at busy times, plus a slow dashboard while cached pages still load fast.
WP Engine’s guide says “a 504 error can occur when too many items are in the backlog and items are evicted”.
It adds that a 502 can occur when requests take too long and are killed to free a worker. Each code is explained in the HTTP status codes reference.
Other signs:
- wp-admin is slow, but the public homepage is fast
- Checkout or login slows down during sales or launches
- Errors cluster at traffic peaks, then clear by themselves
- Your host’s dashboard, if it shows worker use, sits at the maximum
These symptoms can also come from slow plugins or a CPU limit, so check those too.
What to do if you run out of PHP workers
Fix what wastes workers first, then upgrade if your uncached traffic is still too high.
- Improve caching. Cache every public page that can be cached, so workers stay free for the rest.
- Find slow requests. A slow plugin or query holds a worker longer. Fixing it is like adding workers.
- Reduce background calls. Frequent AJAX calls and heavy cron jobs use workers too.
- Block bad bots. Crawlers that hit uncached URLs take workers from customers.
- Upgrade the plan. If uncached traffic is real, move to a plan with more workers and the CPU to run them.
For stores and membership sites that have outgrown their plan, the managed WordPress plans compared show what each host includes.
Frequently asked questions
What is a PHP worker in simple terms?
A PHP worker is a server process that builds one uncached page at a time. If you have 4 workers, your site can build 4 dynamic pages at once.
Do more PHP workers make my site faster?
Not directly. More workers let your site handle more uncached requests at the same time. Each page builds no faster unless the server also has enough CPU and RAM.
How many PHP workers does WooCommerce need?
It depends on how many shoppers use the cart and checkout at the same moment. Estimate it from peak uncached requests per second times average response time, then add headroom.
What happens when all PHP workers are busy?
New requests wait in a queue. If the queue grows too long or requests take too long, visitors can see 502 or 504 errors.
Does shared hosting have PHP workers?
Yes, every PHP host runs worker processes. Most shared hosts don’t publish a worker number, so you usually see the limit through other caps such as entry processes.
How we researched this
The explanation of how workers run follows three official sources, all read October 3, 2026: the PHP-FPM manual, WP Engine’s PHP worker documentation, and WooCommerce’s caching guidance.
Worker counts for WPX and Hostinger were taken from their own pricing pages and rechecked on October 4, 2026.
The Hostinger Cloud Startup count also matches what our own account shows. We bought that plan in November 2025.
The bot observation covers only the first three days of our Kinsta WP 2 account, starting on August 27, 2026. Both accounts are recorded under the first-party testing rules.
