The first time one of my WooCommerce stores threw 504 errors during a sale, the CPU graph looked healthy — barely 40% load. The server wasn’t out of power. It was out of PHP workers. Every worker was busy building a page, checkout requests were stacking up in a queue behind them, and after 60 seconds the queue gave up and served errors to paying customers.
PHP workers are the most under-explained line item in WordPress hosting — hosts bill by them, cap them, and upsell them, yet most plan pages barely define them. Here’s what they actually do, a sizing rule you can apply in two minutes, and the worker-limit table the hosts won’t publish side by side.
In this guide
What a PHP worker actually does
A PHP worker is one process that can build one uncached WordPress page at a time. When a request hits your site, one of two things happens. If the page is in cache, the server hands back a pre-built copy — no worker involved, effectively free. If it isn’t cached — a logged-in user, a cart, a checkout, a search, a REST or admin-ajax call — a worker picks it up, loads WordPress, runs your theme and every active plugin, queries the database, assembles the HTML, and only then frees up for the next request.
Think supermarket checkout lanes. Cached pages are the self-serve shelf by the door. Everything else has to go through a lane, and your worker count is how many lanes exist. Two workers means two uncached requests can be processed simultaneously — the third waits in line, no matter how powerful the rest of the server is.
How many PHP workers do you need?
The rule of thumb I size against: one PHP worker handles roughly 1–2 uncached requests per second, assuming your average PHP response time is in the 500ms–1s range. So the real question isn’t traffic — it’s how much of your traffic bypasses the cache.
- Brochure site or blog with full-page caching. 95%+ of hits never touch PHP. 2 workers is genuinely enough.
- Busy blog with search, comments, and logged-in authors. 2–4 workers.
- Small WooCommerce store (under ~50 orders/day). 4–6 workers. Cart, checkout, and my-account pages bypass cache by design.
- Busy WooCommerce, membership, or LMS site. 6–10 or more. Nearly every pageview here is personalized and uncacheable.
The multiplication that trips people up: worker capacity and code speed are the same lever. Four workers at a 1-second average response clear about 4 uncached requests per second — roughly 14,000 an hour, plenty for most stores. Let a slow plugin drag average response to 3 seconds and those same four workers now clear barely 1.3 per second. Your capacity just fell by two-thirds and you didn’t change plans.
PHP worker limits by host
This is the table I wish someone had shown me before I picked hosting for my first store. Figures are approximate and current at the time of writing — plans change, so treat these as the shape of each host’s policy rather than gospel.
| Workers on entry plan | How you get more | What happens at the limit | |
|---|---|---|---|
| Kinsta | 2 per site (~$30–35/mo) | Plan upgrade or paid worker add-on | Requests queue, then 502/504; dashboard logs worker-limit hits |
| WP Engine | Not published (~$20–25/mo entry) | Plan tier; support tunes concurrency | Concurrency throttling at the edge under heavy load |
| Liquid Web | No per-plan cap | You tune PHP-FPM yourself; bounded by RAM/CPU | Server resources, not policy, set the ceiling |
| Cloudways | No per-plan cap (~$11–14/mo) | Resize the server; workers scale with it | Bounded by the server size you chose |
Notice the split. Kinsta and WP Engine sell fixed allocations — predictable, well-monitored, and excellent for the sites they fit, but you buy headroom in steps. Liquid Web and Cloudways sell resources — the worker ceiling is whatever your hardware can hold, which favors dynamic-heavy sites. That philosophical split is most of the argument in our Liquid Web vs Kinsta comparison, and it’s why the verdict there flips depending on how much of your traffic is uncacheable.
Why too few workers causes 504 errors
The failure mode is a queue, not a crash. When every worker is busy, new uncached requests wait. If the wait exceeds the gateway timeout — usually 60 seconds — the visitor gets a 504. If PHP-FPM’s own backlog fills, they get a 502 instead. Same root cause, different error page.
The diagnostic signature is distinctive: errors arrive in bursts under load while CPU and memory look fine, and they hit dynamic pages first — checkout fails while the cached homepage loads instantly. On my sites the usual triggers have been a sale or email blast landing all at once, bots hammering uncacheable search and filter URLs, wp-cron pile-ups, and — sneakiest of all — a slow payment gateway holding workers open for 10+ seconds per checkout while the API on the other end struggles. Confirm it in your host’s dashboard (Kinsta logs worker-limit hits explicitly) or look for “upstream timed out” lines in the error log.
How to need fewer workers
Before you pay for more workers, make the ones you have finish faster. Every 50% cut in average response time effectively doubles your worker capacity — for free.
- Get full-page caching right. Audit what’s excluded. I’ve seen stores where a misconfigured plugin excluded every URL with a query string — one UTM-tagged campaign turned the whole site uncacheable.
- Add object caching (Redis). Repeat database queries come from memory, responses finish sooner, workers free faster. The single biggest win on most WooCommerce sites I’ve tuned.
- Hunt slow plugins and queries. Query Monitor or your host’s APM will name the offender. One slow plugin taxes every single uncached request.
- Move wp-cron to a real cron job. Otherwise scheduled tasks piggyback on visitor requests and steal workers at the worst moments.
- Rate-limit the bots. Crawlers love faceted search and add-to-cart URLs — 100% uncacheable, 0% revenue.
More workers, or a different host?
If you’re on a fixed-allocation host and you’ve bought worker add-ons twice, stop and do the math. Add-ons stack up fast, and at some point you’re paying boutique prices for capacity a resource-based plan includes by default. That trade-off — polish and managed guardrails versus raw headroom — is the honest version of the is managed WordPress hosting worth it question, and for stores specifically I’ve laid out where the tipping point sits in our best WooCommerce hosting for small stores guide.
My own shorthand after running sites on all four hosts above: content sites almost never outgrow a fixed allocation, and stores almost always do. If you’re weighing the two premium fixed-allocation options against each other first, start with Kinsta vs WP Engine — workers are only one line in that fight.
Frequently asked questions
What are PHP workers in WordPress?
PHP workers are the server processes that build uncached WordPress pages. Each worker handles one request at a time — loading WordPress, running plugins, querying the database, and returning HTML. Your worker count is the number of uncached requests your site can process simultaneously.
How many PHP workers do I need for WooCommerce?
Most small stores run well on 4–6 workers; busy stores need 6–10 or more. WooCommerce needs more than content sites because cart, checkout, and account pages bypass caching entirely, so a much larger share of requests requires a worker.
Do PHP workers matter if I use a caching plugin?
Less — but they still matter. Caching removes most anonymous pageviews from the worker pool, which is why a well-cached blog survives on 2 workers. But logged-in users, carts, checkouts, search, and API calls always bypass cache, and those are usually the requests you can least afford to fail.
Can too few PHP workers cause 504 errors?
Yes — it’s one of the most common causes on managed WordPress hosting. When all workers are busy, new requests queue, and once the wait passes the gateway timeout the server returns a 504 (or a 502 if the backlog fills). The tell: errors during traffic spikes while CPU usage still looks low.
Does adding more PHP workers make my site faster?
Not directly. Workers add concurrency, not speed — page generation takes the same time whether you have 2 workers or 10. More workers stop requests from queueing under load. If pages are slow with no traffic, fix the code and the caching; workers won’t help.
Want the guided version? Our free courses walk you through this start to finish — including “Launch Your First Website with Claude.”