What the Missed Schedule Error Is Telling You
Missed schedule means WordPress never ran the job that was supposed to publish your post. The post is fine. It still exists, it still has the status future, and it will go out the moment that job finally runs. So the repair is never in the post. It is in the scheduler behind it.
This is for people who write ahead: a blog queued on Friday for Monday morning, a sale page timed for nine o'clock, a client site where somebody else will spot the red text before you do. The mechanism is identical in all three, and so is the repair.
The Red Text Comes from One Comparison
WordPress prints those two words when a post still has the status future and its publish time has already passed. The posts list runs the check itself. If 'future' === $post->post_status and the time difference is greater than zero, the column shows Missed schedule in place of Scheduled, as the source of the date column shows.
That makes it a comparison of two numbers, with a message that the second is late, and no more than that. Nothing inside the post is damaged. It also explains why opening the post and clicking Update often seems to fix things: saving a future post schedules the publish job again, and this time something happens to run it.
WP-Cron Waits for a Visitor
WordPress has a scheduler, but not in the sense a server administrator means. The handbook is blunt: WP-Cron "works by checking, on every page load, a list of scheduled tasks to see what needs to be run", and it "does not run constantly as the system cron does; it is only triggered on page load".
Its own example describes your situation: "Scheduling errors could occur if you schedule a task for 2:00PM and no page loads occur until 5:00PM." Your post was never forgotten. Nobody came to the door, so nobody checked the list.
Low Traffic Is the Most Common Cause
A busy site rarely sees this, because somebody triggers the check within a minute or two of the scheduled time. A site with forty visitors a day has long gaps, and the gaps stretch at exactly the hours people schedule for: early morning, late evening, weekends.
Know this before you go shopping for plugins. A quiet site is not broken. Its publishing depends on an audience that has not shown up yet, which is a design detail and not a fault.
Caching Means Fewer PHP Requests Than Your Traffic Suggests
Busier sites get caught by this version. Full page caching, whether in a plugin, at the host, or on a CDN edge, answers most visitors with stored HTML. WordPress never boots for those requests, so nothing checks the schedule. The better your cache hit rate, the quieter your scheduler gets.
The symptom is confusing. Traffic is healthy, the dashboard looks normal, and scheduled work still runs late. If you tightened caching recently and posts began missing their slot afterward, those are one event, not two. It is one reason performance work and maintenance work belong in the same conversation.
The Sixty Second Lock and the Job That Holds It
WordPress will not let two cron runs overlap. When a run starts it sets a doing_cron transient, and a comment in core states the rule: "Don't run if another process is currently running it or more than once every 60 sec." That window is WP_CRON_LOCK_TIMEOUT, 60 seconds by default, and the logic sits in spawn_cron().
You never notice the lock until one event is slow. An import walking ten thousand rows, or a plugin calling an external API with no timeout, can hold the run while everything behind it waits. That includes the job meant to publish your post at nine.
Check the Clock Before Anything Else
Every post carries two dates: the local one you see in the editor and the UTC one WordPress schedules against. If the timezone under Settings, then General is wrong, or was changed after the post was queued, the post goes out at the right moment in the wrong time zone, and everyone decides the scheduler is broken.
Here is a quick test. Open Settings, then General, and read the local time WordPress prints. If it disagrees with your clock, you have a clock problem, not a cron problem. The two look the same until you fix the clock.
Fixing It So It Stays Fixed
Two repairs are real, and a lot of advice is neither. First find out whether the event still exists. Then give WordPress a scheduler that does not depend on visitors.
Look at the Queue Before Changing Anything
With WP-CLI on the server, wp cron event list prints every scheduled event with its next run time. Scan down for publish_future_post. There are two possible findings, and they point in opposite directions.
If the event is there with a time in the past, the queue is fine and nothing is running it, so read the next two sections. If the event is missing, the schedule was lost rather than missed, usually by an import, a migration, or a plugin that cleared the cron array. Opening the post and saving it puts the event back. Running wp cron event run --due-now clears everything overdue in one go, and it is the fastest way to tell which of the two you have.
Turn WP-Cron Off and Drive It From Real Cron
This is the fix that holds. Add one line to wp-config.php, above the comment telling you to stop editing:
define( 'DISABLE_WP_CRON', true );
Then have the server call the scheduler at a fixed interval. The handbook's example for hooking WP-Cron into the system task scheduler runs daily: 0 0 * * * wget --delete-after http://YOUR_SITE_URL/wp-cron.php. That suits the general case and is far too slow for publishing. When a post has a slot to hit, run it every five minutes.
Do not skip the constant. Add the crontab entry without it and both mechanisms run, which makes the site busier and no more reliable.
The Request Has to Reach PHP, Not a Login Prompt
A server cron that gets a 401 does nothing. Three things break it quietly: HTTP authentication on a staging or pre-launch site, a firewall or bot rule that treats a command line user agent as a crawler, and a redirect from the URL in your crontab to the canonical one.
Where you can, skip HTTP and use WP-CLI: */5 * * * * cd /path/to/site && wp cron event run --due-now. That never touches the web server, so authentication, caching rules, and loopback problems cannot break it. On shared WordPress hosting without shell access, the wget or curl version is what you have, and it works as long as the URL it calls returns a 200.
Check the Loopback Before Blaming the Schedule
Open Tools, then Site Health. WordPress runs its own tests there, and two cover this exact subject: whether scheduled events have failed, and whether the site can complete a loopback request to itself. A failed loopback means WordPress cannot call its own wp-cron.php even when a visitor does arrive. That is a hosting or DNS condition, not a WordPress setting, and no plugin will talk it round.
Site Health also shows how old the problem is. The scheduled events test reports everything overdue, not only the post you were hunting for, and the list is usually longer than expected.
Republish Plugins Fix One Symptom
Some plugins exist only to find posts stuck at future and publish them. They work. On a small blog where the only scheduled thing that matters is a post, that may be enough.
Know what you are buying, though. The plugin is a second scheduler on the same weak foundation, and it only watches posts. Everything else in the queue is still late. You came for a missed post, but the rest of the list is the reason to stay.
What Else Was Running Late While You Looked at the Post
Backups. Update checks. Sitemap regeneration. Session and transient cleanup. Retries on transactional email. Abandoned cart mail in a store. Subscription renewals. None of them announce themselves, and all sit in the same queue as the post that gave the scheduler away by turning red in an admin screen.
Email hurts most, because it fails without a trace on the site. If your forms and receipts go out through the server's default mailer, a dead cron queue and a broken mail path look the same from outside: nothing arrives and nothing is logged. Sending through a real delivery path, whether a relay you already pay for or our Email Delivery for Cloudflare plugin, at least puts the failures where you can read them. The wider argument is on the transactional email page.
We made the same point from the other direction when writing about what maintenance mode does not protect you from: the parts of a WordPress site with no browser attached are the parts nobody is watching.
Where This Lands Once Somebody Owns It
A scheduler that depends on traffic is fine until the day something was timed to matter. The durable setup is plain: the constant set, a real cron entry at five minute intervals, and something that notices when the queue stops draining before a customer does.
People skip that last piece, and it is the substance of managed WordPress maintenance. We run WordPress plugin updates, theme updates, and core updates on a consistent schedule, back up your site every 24 hours with 180 days of cloud retention, scan for malware every 24 hours, and monitor uptime 24/7, with site error monitoring and daily form submission testing alongside it. To see how that compares with running it yourself or with a dashboard tool, the maintenance comparisons set it out. Sites with heavier custom work usually need a closer look instead, because a cron queue that jams every week is normally one plugin's fault and worth finding.
