PHP Workers Explained

PHP workers process dynamic WordPress requests. This article explains when they are used, how to recognize worker exhaustion, and when a larger plan helps.

What uses a PHP worker

One PHP worker handles one PHP request until it finishes.

Common examples include:

• Uncached page views
• wp-admin and login requests
• WooCommerce cart, checkout, and account pages
• Logged-in membership or LMS pages
• REST API and AJAX requests
• Webhooks
• WP-Cron and background jobs

Static files and pages served from Cloudflare or full-page cache normally do not use a PHP worker.

Redis can reduce database work, but the request still uses a worker.

Workers by plan

• Core: 8 workers
• Growth: 18 workers
• Pro: 24 workers
• Scale: 36 workers

More workers allow more PHP requests to run at the same time. They do not make one slow request faster.

See FlyingHost Plans and Resource Limits for the complete CPU, RAM, storage, database, cache, and bandwidth limits.

What worker exhaustion means

Worker exhaustion happens when every worker is busy. New PHP requests must wait for one to become available.

For example, eight workers can handle traffic efficiently when requests finish quickly. If each request takes several seconds, a small burst can occupy all eight.

Possible symptoms include:

• Slow uncached pages while static files remain fast
• Slow wp-admin, checkout, REST, or AJAX requests
• Intermittent timeouts or 502/504 errors
• Delayed cron jobs or webhooks
• PHP capacity-limit events in Cockpit

These symptoms can have other causes, so confirm worker usage before upgrading.

Check usage in Cockpit

Open the site and go to Resources. Review:

• Peak PHP workers
• PHP capacity limits
• CPU and memory usage
• Requests and logs from the same time

Use the time range that matches the reported problem. One brief capacity event is not usually important. Repeated events that line up with slow dynamic requests are more meaningful.

Common causes

• Slow plugins, themes, or database queries
• Slow external APIs or email services
• Uncached logged-in or WooCommerce traffic
• Frequent REST API or admin-ajax.php requests
• Aggressive bots or monitoring
• Backups, imports, scans, and cron jobs
• Traffic immediately after a cache purge

Reduce worker usage

1. Find the slow URLs and check logs.
2. Fix or replace inefficient plugins and theme code.
3. Cache eligible anonymous pages.
4. Use Redis object caching for repeated database work.
5. Reduce excessive AJAX or REST polling.
6. Stagger heavy cron jobs and use smaller batches.
7. Investigate slow database queries.

When to upgrade

Consider a larger plan when capacity-limit events are frequent, occur during legitimate traffic, and continue after optimization.

Upgrade for sustained concurrency—not to hide one slow request. Running more slow requests at once can move the bottleneck to CPU, memory, MariaDB, or an external service.

When contacting support, include the affected URL, time and timezone, Resources screenshots, relevant logs, and whether the traffic was anonymous, logged-in, WooCommerce, API, cron, or bot traffic.

Updated on: 03/08/2026