WordPress high CPU usage: find the work behind the spike

WordPress high CPU usage is a symptom of work being done, not a diagnosis. That work might be legitimate traffic, an expensive request, a scheduled backup, repeated bot hits, or a faulty component. Match the CPU spike to a time, process, and request before deciding whether to optimize or upgrade.

A small visitor count does not rule out a busy server. Analytics can miss bots, background jobs, and requests that fail before tracking code runs. One slow uncached endpoint can consume more resources than many cached article views.

Understand the metric you are looking at

Ask whether the graph shows a percentage of one core, an account quota, total server capacity, or CPU seconds over a billing interval. These numbers are not interchangeable. Also establish whether multiple websites share the allowance.

Record the timezone and a short window around the incident. Compare CPU, memory, disk activity, response time, and any resource-fault counters. High CPU with acceptable response times during a planned job calls for a different response from sustained saturation and failed checkouts.

Build a short evidence timeline

The WordPress monitoring handbook recommends profiling and slow logs to identify costly functions, database queries, and external requests. Ask the host for a timestamped example if those tools are unavailable to your account.

Check caching where it is appropriate

The WordPress optimization guide explains the value of caching and reducing unnecessary work. Confirm that eligible public pages are actually served from cache. A cache plugin being installed is not proof of a cache hit.

Keep personalized, cart, checkout, and authenticated responses out of an indiscriminate full-page cache. Check why a supposedly static page bypasses caching: cookies, query strings, exclusions, or an integration can change behavior. Make one controlled change and compare equivalent traffic periods.

Investigate jobs and components

If the spike follows a scheduled import, inspect its batch size, repetition, and failure retries. If multiple expensive jobs overlap, schedule them with adequate separation. Disabling WordPress scheduling without providing a replacement can break publishing and maintenance tasks, so treat scheduling changes as an application change.

On an isolated copy, investigate components implicated by the timeline or profiler. Avoid disabling every live plugin during business hours: payments, forms, and access control may depend on them. A plugin count alone is a poor explanation; the work each component performs matters.

Separate unwanted traffic from capacity growth

Look for repeated expensive searches, login attempts, or unusual request patterns. Apply a targeted rule at the appropriate layer and verify that legitimate visitors and integrations still work. Do not assume every crawler is abusive or every CPU spike is malware.

If normal uncached demand remains above the allocation after reasonable optimization, ask for a plan with a documented increase in the constrained resource. More disk space is not more CPU. A move to a self-managed server also adds maintenance work.

Send support a useful incident report

Include the exact time window, affected URLs, observed errors, recent changes, and relevant graphs with secrets removed. Ask which limit was reached, its scope, and whether the account was throttled. If you see a 508 resource message, use the separate entry-process investigation.

Judge the fix by fewer failures and healthy response times under comparable demand. A lower CPU graph created by blocking real customers would solve the wrong problem.