Why Your WordPress Site Randomly Slows Down — and Why WP-Cron Is Usually Behind It

Your WordPress site is fast. Then, with no pattern anyone can spot, a page takes six seconds. You reload and it's fine again. Nothing in your traffic graph explains it, the host says the server is healthy, and the plugin you suspect turns out to be innocent.

The usual culprit isn't a plugin being slow. It's when a plugin decides to do its work — and in WordPress, that decision is made by a system called WP-Cron that behaves nothing like the cron you're thinking of.

WP-Cron is not cron

Real cron is a scheduler run by the operating system. It fires at 3:00 AM because it is 3:00 AM.

WP-Cron has no clock. It's a list of due tasks that WordPress checks when someone loads a page. On every request, WordPress asks "is anything overdue?" and if so, it fires off a request to wp-cron.php to run it.

That single design choice produces two opposite failure modes, and most sites suffer from one of them.

Low-traffic sites: tasks run late, or never

If nobody visits between 2 AM and 9 AM, nothing scheduled in that window happens until the first visitor arrives. Scheduled posts publish hours late. Backups skip. Subscription renewals, licence checks and feed imports drift.

The classic symptom is a "Missed schedule" error on a post that was supposed to go out overnight.

High-traffic sites: your visitor pays for the task

This is the one that produces the mystery slowdowns. When a heavy job comes due — a backup, a database sync, an import, an analytics rollup — it doesn't run on a quiet background thread. It's triggered by a real person's page request.

Someone gets a slow page not because your site is slow, but because they had the bad luck to be the visitor who tripped the timer. That's why the slowdowns look random. They are random, in the only sense that matters: they land on whoever happens to be there.

Worse, tasks can pile up. Two overdue jobs can fire near-simultaneously on separate requests, and now you have concurrent heavy work competing for the same PHP workers and database.

How to confirm this is your problem

Before changing anything, verify. The symptom pattern that points at WP-Cron:

• Slowdowns with no correlation to traffic volume — they happen at low traffic too
• Time-to-first-byte spikes, not slow assets. The server takes long to respond at all
• The admin feels sluggish at unpredictable moments
• Slow requests correlate with wp-cron.php entries in your access log

Then look at what's actually scheduled. The WP Crontrol plugin lists every registered event, its next run time and its hook. What you're hunting for:

• Events every minute or every five minutes. Almost nothing needs that.
• Orphaned events from plugins you removed. WordPress keeps firing hooks with no handler, and some plugins never clean up on uninstall.
• Duplicate events — the same hook registered several times, which happens after migrations and restores.
• One expensive hook doing far more work than its name suggests.

Also check your autoloaded options. Every single request loads all options marked autoload = yes, so if a plugin has been dumping data into wp_options for two years, you're paying for it on every page load — cron or no cron.

The fix: hand scheduling to the server

The standard fix has two halves, and doing only the first half breaks your site.

Step one — stop WordPress triggering cron on page loads. In wp-config.php:

define('DISABLE_WP_CRON', true);

Step two — have the server run it on a real schedule. A system cron entry every five minutes:

*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Or, better if you have WP-CLI available, because it skips the HTTP layer entirely:

*/5 * * * * cd /path/to/site && wp cron event run --due-now > /dev/null 2>&1

The footgun: plenty of "speed up WordPress" advice lists step one and never mentions step two. Setting DISABLE_WP_CRON alone means scheduled posts never publish, backups silently stop, and subscription renewals quietly fail — with no error message, because nothing is broken. It just never runs. If you've ever added that line from a tutorial, go check whether anything is calling wp-cron.php now.

Most quality managed WordPress hosts do this for you: they disable WP-Cron and drive it from system cron by default, which is one of the less glamorous but more valuable things you're paying for.

See Kinsta's managed WordPress hosting

Beyond cron: the other background costs

WP-Cron gets the blame, but it's one of several background activities that surface as random slowness:

• Transient churn. Plugins storing short-lived cache entries in the database can generate constant writes and, on sites without a persistent object cache, an ever-growing options table.
• Database syncs and external API calls made during a request. An API call with a generous timeout will hold a page hostage for as long as the remote server takes.
• Search and taxonomy queries on large content sets, which are exactly the requests a page cache can't help with.
• Crawler traffic, which hits uncached URLs far more than humans do — a growing problem we covered in why AI crawlers skip badly built WordPress sites.

Caching hides some of this, but it hides it only for logged-out visitors on cacheable URLs. Anything in an admin session, a cart, or a checkout goes straight through to PHP — which is why page-cache benchmarks make sites look faster than they behave. Our look at WP Rocket's built-in CDN covers where caching genuinely helps.

A sane checklist

1. Audit what's scheduled with WP Crontrol. Delete orphaned and duplicate events.
2. Question anything running more often than hourly. Most plugins default to more frequent than they need.
3. Disable WP-Cron and set up a real cron job — both halves, always.
4. Check autoloaded options size. Anything over a megabyte deserves investigation.
5. Add a persistent object cache (Redis or Memcached) if your host offers one. It takes transient traffic out of the database.
6. Re-measure. Watch time-to-first-byte over a few days, not one test. One good result proves nothing.

Bottom line

Random WordPress slowdowns usually aren't random. They're scheduled work firing on a visitor's request, because WP-Cron has no clock of its own and borrows one from whoever shows up.

Move scheduling to the server, prune what's registered, and the spikes typically go with it. Just don't set DISABLE_WP_CRON without setting up the real cron job — that doesn't fix the problem, it only makes the symptoms disappear along with your scheduled posts.