A WordPress server reaches high CPU when runnable work exceeds available processing capacity for long enough. The root cause may be traffic, bots, cache misses, PHP code, database work, cron, queue workers, image processing, external services, or infrastructure contention. CPU percentage alone cannot identify which one.
First response: confirm the time window and business impact, preserve metrics and logs, control harmful traffic, identify the process consuming CPU, correlate requests and jobs, then change one evidence-backed cause at a time.
Is 90% CPU always a problem?
A brief peak can be normal during a deployment, cache warmup, import, backup, or campaign. Sustained saturation with growing response time, queueing, errors, missed jobs, or unavailable admin screens is a reliability incident. Compare CPU with load, steal time, PHP worker usage, memory, disk I/O, database load, request latency, and error rate.
Common root-cause categories
- A traffic increase, crawl, brute-force attempt, or expensive uncached endpoint
- Full-page or object-cache misses and low cache hit rates
- Slow PHP paths, repeated hooks, inefficient loops, or excessive remote calls
- Expensive database queries, lock contention, missing indexes, or oversized working sets
- WP-Cron, Action Scheduler, imports, exports, feeds, backups, or image generation
- Too many concurrent PHP workers creating database and memory pressure
- A dependency timeout that keeps workers occupied
- Noisy-neighbor or virtual-machine contention, visible through infrastructure metrics
Diagnose in the right order
1. Establish the incident window. Record when CPU rose, which journeys slowed, deployments, campaigns, imports, plugin changes, and upstream incidents.
2. Identify the consuming process. Separate web server, PHP-FPM, database, queue, backup, image, and operating-system activity. Host-level CPU cannot prove WordPress is responsible.
3. Correlate requests. Group access logs by path, status, method, user agent, cache result, response time, and source. Protect personal data and avoid blocking legitimate crawlers or integrations without evidence.
4. Inspect PHP. Use application performance monitoring or a profiler to find expensive transactions, hooks, plugins, templates, and external calls. Query Monitor is useful in controlled testing but is not a complete production profiler.
5. Inspect the database. Review slow queries, query plans, locks, rows examined, buffer pressure, connection usage, and table growth. A high query count is not automatically worse than one very expensive query.
6. Inspect background work. Review WP-Cron, Action Scheduler, CLI jobs, webhooks, imports, backups, search indexing, and retry storms. Confirm schedule, duration, backlog, failure, and concurrency.
Stabilize before optimizing
- Rate-limit or block clearly abusive traffic at the edge.
- Pause nonessential imports, backups, crawls, or workers through an approved procedure.
- Restore a known release if the incident follows a deployment.
- Increase capacity temporarily only when it reduces immediate business risk.
- Protect checkout, login, publishing, API, and health-check paths.
- Keep an incident timeline and preserve evidence for root-cause review.
Fixes by evidence
- Improve cache coverage and invalidation when misses drive repeated work.
- Bound queries, use appropriate APIs, reduce repeated lookups, and add indexes only after plan review.
- Move suitable repeated objects into a persistent object cache and measure hit rate.
- Batch background jobs, cap concurrency, add backoff, and make retries idempotent.
- Cache or asynchronously process slow external integrations.
- Reduce unnecessary plugins only when profiling shows their cost.
- Tune PHP workers, database resources, and infrastructure to the measured workload.
What not to do
- Do not upgrade hosting and declare the incident solved.
- Do not disable random plugins on production without a rollback plan.
- Do not run database cleanup or optimization during saturation without understanding locks.
- Do not clear every cache repeatedly, which can create a cache stampede.
- Do not blame WP_Query, cron, bots, or the database without evidence.
- Do not publish debug output or customer data while investigating.
Verification and prevention
- Replay representative anonymous, logged-in, checkout, admin, REST, cron, and queue workloads.
- Compare latency percentiles, errors, throughput, CPU, workers, database time, and cache hit rate.
- Add capacity thresholds, saturation alerts, queue-age alerts, and synthetic business journeys.
- Define performance budgets and load tests for important releases.
- Document the root cause, contributing conditions, failed detection, fix, owner, and follow-up.
A WordPress performance audit or architecture and reliability audit can turn the incident evidence into a prioritized remediation plan.
Primary sources
Frequently asked questions
Common causes include traffic, cache misses, slow PHP, database work, cron or queues, image processing, external calls, and infrastructure contention. Measure before choosing.
Not necessarily. A query can be cheap or expensive depending on arguments, indexes, data size, caching, and frequency.
It may provide temporary capacity, but recurring saturation returns if the workload or defect remains. Diagnose and validate the root cause.
Yes, as can themes, custom code, traffic, databases, jobs, and external systems. Profiling should identify the expensive path.
Only with a reason. Clearing a working cache during high load can increase CPU by forcing many requests to rebuild cached data.
Include impact, timeline, evidence, root cause, contributing factors, mitigation, verification, detection gaps, owners, and prevention work.
