PHP Workers Explained: How Many Your WordPress Site Needs

PHP workers (Kinsta now calls them PHP threads) are the processes that build uncached WordPress pages, and each one handles 1 request at a time. Kinsta's smallest single-site plan includes 2, its 500k-visit plan includes 8, and when all of them are busy, new requests wait in line; if the wait runs long enough, visitors see 503 or 504 errors (Kinsta PHP threads documentation, checked October 12, 2026). Worker count, not storage or bandwidth, is often the limit a busy WooCommerce or membership site hits first.

What a PHP Worker Does

WordPress is written in PHP. When a visitor requests a page that is not already cached, the server hands the request to a PHP worker. The worker runs WordPress, queries the database, assembles the HTML, and returns it. Then it is free for the next request.

Kinsta's documentation puts it plainly: each thread processes one request at a time, and if all threads are busy, additional requests wait until one becomes available. Two consequences follow.

• Workers cap concurrency, not traffic. A site with 2 workers can serve heavy monthly traffic if almost every page comes from cache. The same site can stall with modest traffic if most requests need PHP.
• Slow requests hold workers longer. A request that takes 2 seconds ties up a worker 10 times longer than one that takes 200 milliseconds. Slow plugins, slow database queries, and slow external API calls all eat worker capacity.

Which requests need a worker

Kinsta's rule of thumb: cached content does not need PHP threads; they are needed when the site has to query the database to get or change information. In practice, on a typical WordPress site, that means:

• Usually cached (no worker): blog posts and static pages for logged-out visitors, images, CSS, and JavaScript.
• Usually uncached (worker needed): cart and checkout pages, logged-in member areas, the WordPress admin, search results, form submissions, and many background AJAX and REST API calls.

That split explains why a content blog and a WooCommerce store with the same visit count need very different plans. The blog serves most traffic from cache. The store sends every shopper who adds to cart into the PHP queue. A CDN helps the cached half and does little for the uncached half, as covered in the guide to what an included CDN speeds up.

PHP Workers by Plan: Kinsta as a Worked Reference

Few hosts publish worker counts per plan. Kinsta does, which makes it a useful reference for what the numbers look like as plans scale. The table below lists Kinsta's single-site plans, read from its documentation on October 12, 2026. Plan names and limits change; check the live page before buying.

Source: Kinsta PHP threads documentation, checked October 12, 2026. Verdict column is HostingDive's sizing guidance, not a Kinsta recommendation. For the plan prices that go with these tiers, see the Kinsta review.

Two patterns are worth noticing. Workers grow slower than visits: going from 35k to 3.15M visits multiplies the visit allowance by 90 and the thread count by 8. And memory per thread steps up at the higher tiers, which matters for heavy plugins that run out of memory rather than out of workers.

More Workers Is Not Always the Fix

Adding workers sounds like the obvious answer to 503 errors. It often is not.

Kinsta's documentation warns that adding threads without enough CPU and RAM to support them creates a bottleneck instead of removing one. Each worker needs processor time and memory. On a server that is already short of CPU, more workers means more requests fighting for the same cores, and each request gets slower.

The same documentation notes that memory-limit errors are not solved by more threads. A plugin that exhausts PHP memory needs more memory per thread or a fix to the plugin, not a larger queue.

How to Tell If Workers Are Your Bottleneck

1. Check when errors happen. 503 or 504 errors that cluster around sales, email sends, or course launches point to worker exhaustion. Errors at random quiet hours point somewhere else.
2. Look at what the busy requests are. Most managed WordPress hosts show slow or top requests in their dashboard or through an APM tool. If admin-ajax.php, checkout, or a search endpoint dominates, those requests are holding workers.
3. Measure uncached response time. Load a cart or logged-in page with caching bypassed. If it takes well over a second, the first fix is speed, not more workers.
4. Ask the host for the number. If a plan page does not list worker or thread counts, ask support directly. A host that cannot say how many PHP processes a plan gets cannot tell you how much uncached traffic it will handle.
5. Upgrade only after the above. If requests are already fast and the queue still fills at peak, more workers on a plan with matching CPU and RAM is the right move.

PHP Workers vs the Other Numbers on a Plan Page

Plan pages lead with the numbers that are easiest to market: monthly visits, storage, and bandwidth. Those limits describe volume over a month. PHP workers describe how much uncached work the plan can do in the same second. A plan can be far below its visit allowance and still turn shoppers away at 8 p.m. on a sale day.

Three other figures interact with workers:

• PHP memory per worker: the ceiling for a single request. Page builders, large WooCommerce catalogs, and import plugins hit this first. On Kinsta's single-site plans it is 256MB up to the 750k-visit tier and 512MB from the 1.25M-visit tier upward.
• CPU allocation: rarely published on managed plans, but it decides how fast each worker finishes. More workers on the same CPU share the same processor time.
• Request timeout: the point at which the server stops waiting on a slow request. A long-running import or report can hold a worker until it hits this limit.

When comparing hosts, put the worker count next to the visit allowance. Two plans with the same visit limit can differ in how many uncached requests they process at once, and the host that publishes the number is easier to size than the one that does not.

Shared Hosting and PHP Workers

On shared hosting the same mechanism exists under different names: entry processes, concurrent PHP processes, or CPU limits enforced per account. Shared plans rarely publish them clearly. When a store outgrows those limits, the symptom is often the account throttling or suspension described in the guide to shared hosting resource limits. That is usually the signal to move to managed WordPress, where the worker allowance is stated per plan. The shared hosting vs managed WordPress comparison covers that decision.

How Many PHP Workers Does Your Site Need?

A rough sizing rule, based on the share of traffic that skips the cache:

• Mostly cached content site (blog, brochure, portfolio): 2 workers is usually enough, even at substantial traffic, because few requests reach PHP.
• Small store or membership site: start at 4. Watch peak periods, not monthly averages.
• Store with daily order volume or an LMS with many logged-in learners: 6 to 8, with memory per thread checked against the heaviest plugins.
• High-concurrency dynamic site: 10 or more, and only on a plan with CPU and memory scaled to match.

These are starting points, not guarantees. The right number depends on how long each uncached request takes, which is the variable a site owner controls most directly.

Read the full Kinsta review on HostingDive, or compare managed WordPress hosting options with current intro and renewal pricing in the managed WordPress hosting guide.

Frequently Asked Questions

What are PHP workers in WordPress hosting?

They are the server processes that run PHP to build uncached pages. Each one handles one request at a time, so the worker count sets how many uncached requests a site can process at once.

What happens when all PHP workers are busy?

New requests wait in a queue until a worker frees up. If requests stay busy too long, visitors can see slow loads or 503 and 504 errors, according to Kinsta's documentation.

Are PHP workers and PHP threads the same thing?

Yes, in Kinsta's usage. Kinsta renamed PHP workers to PHP threads; both describe processes that each handle one request at a time.

Do more PHP workers make a site faster?

Not by themselves. More workers increase how many uncached requests run at once, but each request is no faster, and without enough CPU and RAM extra workers can slow things down.