A post scheduled for Tuesday morning is still sitting there on Thursday marked “Missed schedule”. The backup plugin says the last backup ran nine days ago. Renewal emails have stopped going out. These look like three unrelated faults and they are usually one: WordPress cron not running. The scheduled post missed schedule message is the most visible symptom, but it is rarely the only one.
Why it stops, and why quiet sites suffer most
Real scheduled tasks on a server run from a system clock. WordPress does not have one. Instead it uses WP-Cron, which checks whether anything is due each time somebody loads a page.
On a busy site that works well enough — visitors arrive constantly, so the queue is checked constantly. On a quiet site it fails in a way that is almost poetic: a task scheduled for 3am waits until the first visitor of the morning, and if nobody visits for a day, nothing runs for a day.
This is why the problem so often appears on exactly the sites that can least afford it. A brochure site with a handful of visitors a day is the worst case, and it is also the site whose owner is least likely to be watching.
Two other things leave wp-cron not working: a caching layer serving pages without ever reaching WordPress, and DISABLE_WP_CRON being set to true in wp-config.php — which is often correct, but only if a real cron job was set up to replace it and sometimes that second half never happened.
Check whether it is actually the problem
Three signs together make it near-certain: scheduled posts missing their time, a backup plugin whose last run is older than its schedule, and any plugin that sends mail on a timer going quiet. One of those alone might be something else. All three at once is the queue.
A cron viewer plugin will show you the queue, when each task last ran, and when it is next due. Anything showing a next-run time in the past is stuck, and that is your confirmation.
The fix, and the version worth doing properly
The reliable answer is to stop depending on visitors and let the server do it. This is two steps and the second is the one people skip.
Step one: tell WordPress to stop running its own queue on page loads, by setting DISABLE_WP_CRON to true in wp-config.php.
Step two: create a real cron job in your hosting control panel that requests wp-cron.php on a schedule — every fifteen minutes suits most sites. Every decent host offers this, usually under a “Cron Jobs” or “Scheduled Tasks” heading.
Doing step one without step two is worse than doing nothing: the queue then never runs at all. If you are not going to add the server-side job, leave the default alone.
The opposite problem: cron running far too often
On a busy site the fault reverses. Every page load checks the queue, so a site with steady traffic runs that check thousands of times an hour. Usually it is harmless. Occasionally it is the reason a site feels sluggish for no visible cause, because a heavy scheduled task fires on a visitor page load and that visitor waits for it.
The tell is a site that is generally quick but stalls unpredictably, often on the first request after a quiet period. The same fix applies: hand the schedule to a real server cron job and take it off the visitor path entirely. Then a slow task delays a background process instead of a customer.
Tasks that quietly stack up
When the queue has been stuck for a while, everything due during that time is still waiting. The moment it starts running again, all of it fires at once — several backups, a batch of emails, a full scan. On shared hosting that burst can be enough to exhaust the account limits, which makes it look as though fixing cron broke the site.
Two things avoid it. Before enabling a server cron job, look at the queue and delete anything obviously stale — old one-off tasks from plugins you have since removed are common. And expect the first run to be heavier than normal, so do it at a quiet hour rather than mid-morning.
Plugins you have deleted can also leave their scheduled tasks behind. They fail silently every time they are due, forever, because the code they point at is gone. Clearing those out is a small piece of housekeeping that nobody does unprompted.
Do not schedule everything for midnight
A small thing that causes a lot of confusion. Plugins tend to default to running at midnight, so on many sites every heavy task lands in the same minute — the backup, the security scan, the optimiser, the newsletter. They compete for the same resources, some time out, and the ones that fail fail quietly.
Spread them across the small hours instead. The backup at 1am, the scan at 3am, the optimiser at 4am. It costs nothing and it removes a whole category of intermittent failure that is otherwise very hard to diagnose.
The part worth remembering
This fault is not dramatic. Nothing breaks, no error appears, and the site looks completely normal. What actually happens is that your backups stop while you continue believing they are running — and you find out on the day you need one.
Checking that the schedule is genuinely running is a small item on a monthly list, which is where it belongs. Our guide to backing up a WordPress website covers verifying the backup itself, and routine WordPress upkeep is the version where somebody checks the queue every month so a silent stop does not run for a year.