Scheduled posts show “Missed schedule”
The publish time passed and nothing happened. WP-Cron is not a clock — it runs when a request arrives, and no request arrived.
Missed schedule
WP-Cron is triggered by page loads, so a quiet site has nothing to fire it. List the due events: if they are queued with a timestamp in the past, the schedule is fine and the trigger is missing, and a real system cron fixes it permanently.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| No traffic at the scheduled time | Due events pile up with past timestamps and then all run at once the moment you load a page yourself. | Drive cron from the operating system on a fixed interval instead of from visitors, so the queue is worked whether anyone is on the site or not. |
| WP-Cron is disabled and nothing replaced it | DISABLE_WP_CRON is true in wp-config.php, and no scheduled task on the server calls wp-cron.php. | Add the system cron entry that the constant assumes exists. Disabling the visitor trigger without adding a replacement stops every scheduled task on the site, not only publishing. |
| The loopback request fails | Site Health reports that the site could not complete a loopback request. WP-Cron spawns itself over HTTP, so it cannot run if the site cannot reach itself. | Fix the loopback first — it blocks cron, plugin updates and the editor's autosave alike. Calling wp-cron.php through the command line sidesteps HTTP entirely. |
| The site's timezone is not what you think | Posts publish, but an hour or several off. Compare the WordPress timezone setting against the server clock. | Set the timezone to a named city rather than a UTC offset, so daylight saving is handled. An offset is a fixed number and goes wrong twice a year. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
See whether events are queued and overdue
This is the split. Overdue events mean scheduling worked and nothing is running the queue.
wp cron event list --fields=hook,next_run_relative,status
Run the queue by hand
If the backlog clears, the schedule was never the problem and you are looking for a trigger.
wp cron event run --due-now
Turn off the visitor-driven trigger
Add this to wp-config.php. On its own it makes things worse, so do the next step in the same sitting.
define( 'DISABLE_WP_CRON', true );
Give it a real schedule
Every five minutes is enough for publishing and gentle on a small server. Use WP-CLI rather than curl so no HTTP request is involved.
*/5 * * * * cd /path/to/site && wp cron event run --due-now --quiet
Confirm the timezone before blaming cron again
A post that publishes reliably but at the wrong hour is a clock problem, not a queue problem.
wp option get timezone_string date
What the platform takes off the list.
Cron is driven by the platform on a fixed interval rather than by visitors, and the visitor trigger is switched off, so a post scheduled for 3am publishes at 3am on a site with no overnight traffic. Because the runner is the platform's rather than an HTTP request the site makes to itself, a failing loopback does not silently stop publishing.
Questions, answered.
Why did every missed post publish at once when I opened the site?
Is a plugin that “fixes missed schedules” enough?
How often should the system cron run?
Does this affect anything other than posts?
If that was not it.
These fail in ways that look similar from the browser.