WordPress missed schedule: why WP-Cron waits for a visitor, and the real cron fix

What does WordPress missed schedule mean?

A WordPress missed schedule label means the job that publishes the post has not run. It shows in red on the Posts screen when a post’s time has passed and its status still says Scheduled.

That job belongs to WP-Cron, the scheduler built into WordPress. The Plugin Handbook says it handles checking for updates and “publishing scheduled post”.

When posts or store emails slip, this is one of the first things we check on our WordPress care plan.

Why does WP-Cron only run when someone visits?

There is no clock behind it. The handbook says WP-Cron works by “checking, on every page load, a list of scheduled tasks” and runs whatever is due during that load.

It also says plainly: WP-Cron “does not run constantly as the system cron does”. The handbook’s own example is a task set for 2:00 PM with no page loads until 5:00 PM. That task runs at 5:00.

The reason, per the handbook: many hosts are shared “and do not provide access to the system scheduler”.

What did our lab show?

We tested it on a WordPress 7.1.2 copy of our staging store on 11 Oct 2026. A small must-use plugin logged when the post went from Scheduled to Published, and which request did it.

We scheduled a post for two minutes ahead, at 2:38 pm UTC, then left the site alone. At 2:43 the Posts screen showed “Missed schedule” under the date. The cron event was still queued for 2:38.

Then we loaded the home page as a visitor, twice. The post stayed Scheduled.

That surprised us. A visit does not run the jobs itself. It fires a background request from the site to its own wp-cron.php, called a loopback. We think our test copy could not reach itself that way, so the visit did not publish the post. WordPress’s Site Health screen has a check for this exact failure: “Your site could not complete a loopback request”, and it notes loopback requests “are used to run scheduled events”.

At 2:46 we requested wp-cron.php directly, the way a server cron would. The post went live at 2:47:02, more than eight minutes late. One more detail: its date still read 2:38, so nothing on the post tells a reader it went out late.

Which jobs run late besides scheduled posts?

Anything queued through WP-Cron. Plugin and theme auto-updates are one. WordPress’s documentation says they “rely on WordPress Cron tasks to actually perform the update”, and suggests Tools, Site Health to check that cron tasks are running.

Who switched auto-updates on for a plugin in the first place, and what forces them on, is a separate question we tested in who turned on auto-updates for a WordPress plugin.

WooCommerce adds its own queue, Action Scheduler. Its FAQ says the queue is started by WP-Cron by default, plus a hook on admin requests. It also says the library handles “everything from emails to payments”.

If your backup plugin schedules through WP-Cron, a quiet night means a late backup.

Those backups copy every image size too, which is why a 4,000 px photo became 11 files in our lab in the uploads folder.

Caching can make this worse. SiteGround’s guide says caching plugins can interfere with wp-cron.php, so scheduled tasks “may not execute properly and timely”.

A failing job is a different problem from a crashing plugin. For that one, WordPress emails you, and we covered the “technical issue” email WordPress sends after a fatal error separately.

How do you see the WooCommerce queue?

Go to Tools, Scheduled Actions. The Action Scheduler docs say the same screen also sits under WooCommerce, Status, Scheduled Actions.

Filter by Pending and look at the dates. On our test store, four pending actions were past due after a few idle minutes, and the count was back to zero after our next page loads. Action Scheduler’s FAQ says a few past-due actions are normal, but several more than a day old suggest “something wrong with your site”.

How do you set up a real cron for wp-cron.php?

The handbook gives two steps, in this order.

First, ask your host’s scheduler to request wp-cron.php on a timer. On cPanel that is the Cron Jobs screen. On SiteGround it is Site Tools, Devs, Cron Jobs. The handbook’s Linux example runs every 15 minutes:

*/15 * * * * wget --delete-after https://example.com/wp-cron.php

Then switch off the page load trigger in wp-config.php, above the “stop editing” line:

define( 'DISABLE_WP_CRON', true );

Do the cron first. With the constant set and no cron, nothing runs at all.

How often is up to you. SiteGround suggests 30 minutes for most sites. When we take on a site with scheduled posts or a store, we turn off the visit trigger, add a server cron every five minutes, and check the Scheduled Actions list the next morning.

What should you check today?

Open the Posts screen and look for red “Missed schedule” labels. If you run WooCommerce, filter Scheduled Actions by Pending.

If either list has old dates, tell us what is running late and we will check how your site’s cron runs.