CPU usage is the share of processor time the server is spending running code on behalf of your site. On a WordPress server that code is mostly PHP (running WordPress core, plugins, and themes), MySQL or MariaDB (running queries against the database), and the web server itself (nginx or Apache). When that share approaches the ceiling, requests stop completing in their usual time and the symptoms you see come from queueing, not from any single broken thing.
What CPU usage actually measures
The number you see in a hosting panel labelled "CPU usage" is almost always one of two things, and they are not the same.
The first is per-core utilization expressed as a percentage. A 4-core server has 400% of CPU available across all cores. A WordPress page build that pegs one core to 100% only consumes a quarter of the machine. When a tool like htop shows 100% on one row and nothing on the others, that is one core saturated, not the whole server. The Linux top(1) man page describes the columns and what they mean: %Cpu(s) breaks the total down into us (user code, like PHP), sy (kernel code), wa (waiting on disk I/O), and a few others. Most WordPress CPU pressure shows up as us time. A high wa figure means the bottleneck is actually disk, not CPU.
The second is load average, the three numbers (1, 5, and 15 minute averages) you see at the top of uptime or top. The Linux kernel documents load average as the average number of runnable or uninterruptible-sleep tasks over the window. Load average is not a percentage. A load of 4.0 on a 4-core machine roughly means "the CPUs are fully booked, with no queue". A load of 8.0 on the same machine means there are about as many tasks waiting as there are running. The shorthand: divide load average by the core count to get a rough utilization figure. Anything above 1.0 per core is sustained pressure.
Hosting panels usually expose one of these numbers and call both of them "CPU". Knowing which one is on screen is the first step to interpreting it.
Why a capped CPU produces slow pages, not errors
Hosting plans cap CPU. On a virtual machine, the hypervisor enforces a fixed number of vCPUs. On shared hosting, CFS (the Linux Completely Fair Scheduler) or a cgroup limit caps the percentage of one core a user account can consume. On managed WordPress platforms, the cap is usually expressed as a quota of CPU seconds per minute. The cap exists because one runaway site cannot be allowed to starve every other site on the same machine.
When a WordPress request needs CPU and none is available, the kernel does not return an error. It queues the process. The request still runs, just later. From the visitor's side, the page now takes longer to start, longer to build, and longer to send. From the server's side, every active PHP-FPM worker is busy waiting for its turn. That backlog is exactly what produces the rising TTFB most monitoring alerts pick up first. If the backlog grows long enough, requests breach the configured timeout, the web server gives up on the upstream, and the visitor sees a 502 or 504. If a single PHP script burns CPU long enough on its own, PHP itself trips its max_execution_time limit and aborts the script.
The design choice to fail by queueing rather than by erroring is deliberate. A queue is recoverable. As soon as the spike subsides, the queue drains and the site recovers on its own. The alternative (refusing requests once the CPU is busy) would turn every minor traffic burst into an outage.
Practical implications for a WordPress site
The CPU is finite and the things that consume it on a WordPress server fall into a small number of buckets.
Uncached PHP requests. Anything that runs WordPress through PHP. Cached pages served from a full-page cache (Varnish, nginx fastcgi_cache, an LSCache or WP Rocket disk cache) bypass PHP entirely and consume almost no CPU. The CPU pressure on a WordPress site comes from the small share of requests that genuinely need PHP: logged-in users, the WordPress admin, WooCommerce cart and checkout, REST API calls, and any uncacheable personalized output. Brute force attack protection covers the dedicated mitigation for bot traffic that exhausts CPU. A site that serves 95% of its traffic from cache can run on a small CPU budget. A site where every page is dynamic cannot.
WP-Cron loops. WordPress runs scheduled tasks through wp-cron.php, triggered by visitor traffic by default. If a plugin schedules a task that fails and reschedules itself, the loop runs on every page load. This shows up as a low but constant CPU baseline that does not match traffic, and as scheduled events that never disappear from wp cron event list.
Slow plugin admin pages. A plugin admin screen that runs an N+1 database query (one query per row, multiplied by hundreds of rows) burns CPU on the database side and on the PHP side at the same time. This is a common cause of the WordPress admin feeling slow even when the front end is fine.
Background scans running during the day. A backup plugin or security scanner that crawls the entire wp-content/uploads (see also WordPress Heartbeat API for admin-ajax.php CPU pressure) directory and hashes every file consumes CPU continuously for the duration of the scan. If the scan is configured to run hourly, the CPU floor never drops.
Taxonomy and term operations on large sites. Sites with tens of thousands of terms (large WooCommerce catalogues, news sites with dense tag taxonomies) can spend significant CPU on term-count recalculation, term-meta queries, and database queries that scale with term count. The WordPress.org performance handbook documents the common high-cost query patterns that fall into this category.
Brute-force and bot traffic. Bots that hammer /wp-login.php or scrape every page on the site consume PHP workers and CPU on requests that produce no real value. The best mitigation lives in front of PHP (rate limiting at the edge, fail2ban on the auth log) because filtering them in WordPress still costs the request.
What high CPU is NOT
Most confusion about "high CPU" comes from conflating it with adjacent problems that have similar symptoms but different fixes. Knowing which one you actually have is the difference between a fix that works and a fix that wastes a weekend.
- Not high RAM. CPU and memory are independent budgets. A site can sit at 10% CPU and run out of RAM (PHP will trip its memory limit or the kernel's OOM killer will start terminating processes). A site can also sit at 100% CPU with plenty of RAM free. Diagnosing one as the other leads to upgrades that change nothing.
- Not high disk I/O. When the bottleneck is disk, processes spend their time in
wa(I/O wait) state. The CPU shows as "busy" in some panels but the cores are not actually computing, they are blocked waiting on the disk.vmstat 1makes the difference visible: highus/syis real CPU pressure, highwais disk pressure dressed up as CPU pressure. The vmstat man page explains the columns. - Not high TTFB. TTFB is the symptom; high CPU is one of several possible causes. A site can have a high TTFB because the database is slow, because an external API call inside the PHP request is slow, or because PHP-FPM is queueing requests. Treating "high CPU" and "high TTFB" as the same thing leads to fixing the wrong layer.
- Not high visitor count. A traffic spike against a well-cached site barely touches CPU because the cache absorbs it. A small number of logged-in users on an uncached site can pin the CPU for minutes at a time. The metric that correlates with CPU is uncached PHP requests per second, not raw visitor count.
- Not a worker shortage. PHP worker exhaustion and high CPU often happen together but they are different failure modes. Workers can be exhausted while the CPU is mostly idle (every worker is blocked waiting on a slow database query). The CPU can be saturated while workers are not exhausted (a small number of workers each doing real CPU work). Adding workers to a CPU-bound site makes things worse, not better, because each new worker now competes for the same scarce CPU.
Where to go next
If the symptom looks like a slow site rather than a clearly-CPU problem, the general "WordPress site is slow" article walks through how to narrow down the layer at fault. If the symptom is concentrated in wp-admin, the slow WordPress admin article covers why the admin saturates resources first. If your monitoring shows queueing rather than raw CPU pressure, the PHP workers article explains the worker pool model that produces it.