WordPress Missed Schedule: Why Scheduled Posts and Sales Fail to Publish

"Missed schedule" is two words in red, sitting in the date column of your Posts screen. WordPress shows it when a post was set to publish at a time that has already passed, and nothing published it. No email arrives. Nothing on the front of the site looks broken. The post just sits there, finished and invisible, while the moment it was written for goes by.

Most owners meet that label once and assume they clicked the wrong button. Sometimes they did. More often, the site's scheduler simply never woke up. This guide is a reference for what that scheduler is, what depends on it, how to verify it is working, and what to change so your planned launches deploy when you planned them.

What "Scheduled" Actually Means in WordPress

When you click Schedule instead of Publish, WordPress does not set an alarm. It writes a note into a list of pending tasks: publish this post at 07:00. Something then has to read that list at or after 07:00 and act on it.

That something is WP-Cron. The WordPress Plugin Handbook is unusually blunt about how it works: it checks the list of scheduled tasks "on every page load", and it "does not run constantly" the way a server's own scheduler does ^[1]. The handbook's own example is a task set for 2pm that does not run until 5pm, because nobody loaded a page in between.

So a scheduled post is really a request. Publish this, the next time someone happens to call by.

On a busy site that difference never shows. Visitors arrive every few seconds and the list gets read constantly. On a small business site, though, traffic is lumpy. Plenty of visitors at lunchtime, very few at 6am, and that early-morning gap is exactly when owners like to schedule things.

The upside nobody mentions

WP-Cron has one genuinely good property. The handbook points out that a missed task is queued and runs at the next opportunity, so you can be confident it runs eventually, even if you cannot be sure when ^[1]. Your post is not lost. It is late. For a blog article that is a minor irritation. For a sale that was meant to open at 7am, late is the whole problem.

Why Small Business Sites Miss More Schedules

Three conditions make missed schedules more likely, and they tend to stack up on exactly the sort of site a local firm runs.

Quiet hours

A site with a few hundred visitors a day can easily go an hour or more overnight without a single page request. Schedule a post for 06:30 and the first visitor might be a customer at 07:40. That visitor triggers the publish. Everything set for that window lands at once, late.

Page caching

Fast hosting caches full pages. A cached page is handed straight to the visitor without WordPress running at all, which is the reason it loads quickly. In practice, that means your customer reading the menu on their phone gets the page in a fraction of the time an uncached page takes, and is far less likely to give up and go elsewhere.

The trade-off is that a cached page view does not run WordPress, so it cannot read the task list either. A well-cached site can serve hundreds of happy visitors in an hour and still not trigger a single scheduled task, because none of those visits reached the part of the stack that checks. We will come back to how to handle that, because the answer is not to switch caching off.

Loopback requests that get blocked

When WP-Cron does decide to run, it usually does so by having the site send a quick request to itself in the background. WordPress calls this a loopback request, and its own documentation notes that loopback requests "are used to run scheduled events" ^[4]. If something on the site blocks the site from calling itself, the tasks never run, however much traffic you get.

The usual culprits are a security plugin set too aggressively, a whole-site password used while the site was being built and never removed, or a maintenance-mode plugin left half-switched on. Any of these creates a dependency conflict that nobody sees until something scheduled fails to deploy.

What Runs on the Scheduler Besides Your Posts

Scheduled posts are the visible symptom. The same scheduler sits underneath a lot of jobs owners never think of as scheduled at all.

What depends on the scheduler	What you see when it stalls	Where to verify it
Scheduled posts and pages	"Missed schedule" in red on the Posts screen	Posts, All Posts, Date column
WooCommerce sale prices	Sale price not showing, or still showing after it ended	Products list and the Scheduled Actions screen
Plugin emails and reminders	Booking reminders or follow-up emails not sent	Scheduled Actions screen, Past-due filter
Automatic updates and housekeeping	Site Health warns a scheduled event failed or is late	Tools, Site Health, Status tab

Each row is covered in turn below.

Scheduled posts and pages

This is the case everyone recognises. Posts and pages set to the Scheduled status are published by WP-Cron, and WordPress's own Site Health text says the scheduler "is also what makes sure scheduled posts are published on time" ^[3]. When it stalls, the post keeps its Scheduled status past its time and the list shows "Missed schedule". Nothing else warns you.

WooCommerce sale prices

WooCommerce lets you set a sale with start and end dates on a product. The switch-over itself is a recurring background job. In WooCommerce's own source code, the job that starts and ends scheduled sales is registered to run once a day, timed for midnight in your site's timezone, through a queue called Action Scheduler ^[6].

Two things follow. First, the product editor takes dates, not times, so a "sale starting Friday" starts when that midnight job runs, not at 9am when you open the shop. Second, if the scheduler stalls overnight, the sale can open late or close late. The second one hurts more. A sale that runs past its end date means customers paying a price you never intended to offer, and the decision about whether to honour those orders.

If clocks are part of your worry here, our guide to the WordPress timezone setting covers the separate problem of a site running an hour out after the clocks change.

Plugin emails and reminders

Action Scheduler is not only for WooCommerce. Its own documentation describes it as a job queue for plugins, and explains that it attempts to run every minute by hooking into WordPress's built-in WP-Cron, with an extra nudge whenever someone uses the admin area ^[5]. Booking plugins, newsletter tools, abandoned-basket reminders and subscription renewals commonly use it or something like it.

When WP-Cron stalls, those jobs back up. Appointment reminders go out late or in a clump. A customer gets their "see you tomorrow" email the morning after their appointment.

Automatic updates and housekeeping

WordPress also uses the scheduler to check for updates and clean up after itself, which the handbook lists alongside scheduled posts as core features that rely on WP-Cron ^[1]. A stalled scheduler here is quieter. Security updates that should apply automatically sit waiting, and the site gets older than you think it is.

The Cost of a Launch That Does Not Deploy

It is worth being concrete about why this matters, because on paper it looks like a small timing glitch.

Consider a hypothetical Carlow farm shop opening Christmas turkey and ham orders. The order page is scheduled to publish at 07:00 on a Saturday in November, and the newsletter announcing it is scheduled to send at 07:05 from a separate email service that has its own reliable clock. The email goes out on time. The page does not, because nobody has visited the site since 5am and every early visitor gets a cached copy of the homepage.

So the most loyal customers, the ones who open the email over breakfast, click through to a page that does not exist yet. A few try again later. Others ring the shop. Some decide that the place down the road, whose order form worked first time, will do this year. By the time anyone in the shop notices, the busiest hour of the busiest booking week has gone, and the fix (logging in and pressing Publish) takes about ten seconds.

That is the typical shape of a missed-schedule failure. The content was ready, and the job of moving it from staging into production was simply never triggered. The damage is not to the website. It is to the moment.

How to Verify Your Scheduler Is Working

Verification takes about five minutes and needs nothing more than your normal WordPress login.

Read the Site Health status

Go to Tools, then Site Health, and open the Status tab. Two results matter for scheduling. The first is the scheduled events test, which WordPress has included since version 5.2. If it is unhappy you will see "A scheduled event has failed" or "A scheduled event is late", followed by the name of the job, and the reassurance that "your site still works, but this may indicate that scheduling posts or automated updates may not work as intended" ^[3]. The second is the loopback test. If it reports "Your site could not complete a loopback request", WP-Cron has no reliable way to run its tasks ^[4].

One late event, once, after a quiet night is normal. The same warning every time you look is a conflict that needs fixing.

Look for past-due actions

If you run WooCommerce or a booking plugin, find the Scheduled Actions screen (WooCommerce adds it under Status). Filter by Pending and look at the dates. A handful of actions due in the next few minutes is healthy. Dozens of actions whose due time was hours ago tell you the queue is not being worked.

Run a harmless test post

Write a two-line draft, schedule it for ten minutes from now, then leave the site completely alone. Come back after twenty minutes. If it published on time, your scheduler is responding to background traffic. If it shows "Missed schedule", you have reproduced the problem safely, on a post nobody will read, rather than on your Christmas launch. Delete it afterwards.

Making Scheduled Launches Reliable

Fixing this properly is a mix of one setting your host controls and some habits you control.

The server-side fix: a real scheduler

The WordPress handbook recommends the proper fix for sites where "there are critical tasks that must run on time": have the server's own task scheduler call WordPress on a fixed interval, every few minutes, and then turn off the page-load trigger ^[2]. Once that is in place, the scheduler runs whether or not anyone visits, and page caching stops mattering to it at all.

This is a server-level change and it is provider-dependent. Some hosts set it up by default, some will do it on request, and some shared hosts do not allow it at all. Ask your host directly whether WordPress scheduled tasks on your site are triggered by a server scheduler or only by visitor traffic. A clear answer to that question tells you more about how a host operates than most feature lists do.

The habits that cover the gap

Whatever your host does, these habits remove most of the risk:

• Schedule into traffic, not silence. 08:30 is far safer than 06:00 on most local business sites. If the timing is not critical, pick a time your site is normally busy.
• Be logged in at launch time. An admin page is never served from cache, so simply opening your dashboard at 06:59 gives WP-Cron the page load it needs. For anything with money attached, this is the cheapest insurance there is.
• Stagger dependent actions. If an email links to a scheduled page, schedule the page well before the email, not five minutes before. Verify the page is in production, then let the email go.
• Rehearse big launches in staging. Set the sale up on a staging copy first, confirm prices and dates behave as expected, then deploy the same settings to production.
• Clear what blocks loopbacks. Remove whole-site passwords and maintenance plugins once the site has launched, and if a security plugin is blocking the site's requests to itself, adjust that rule rather than disabling the plugin.

Caching is not the enemy

It would be easy to read the caching section above and conclude that page caching causes missed schedules, so it should go. That gets it backwards. Caching is why the site is fast, and the complete WordPress performance guide explains how much of a small site's speed comes from it. The fix is to stop relying on visitors to run the scheduler, not to make every visitor wait longer.

The same logic applies to plugins. Some owners install a "cron fix" plugin that pings the site from outside every few minutes. That can help on a host that offers nothing else, but it is one more plugin, one more dependency and one more thing to update. Several of the plugins you stop needing on properly managed WordPress exist only to patch over gaps the hosting should have closed.

Where Web60 Fits, and Where It Does Not

An honest limitation first. Web60 runs Nginx with FastCGI page caching and Redis object caching, which is a large part of why pages load quickly for visitors. That same page caching means a cached visit does not wake WordPress, so on a quiet site the scheduler depends more on uncached activity than it would on a slow, uncached host. Faster pages and visitor-triggered scheduling pull in slightly different directions. Knowing that is the first step to planning around it.

What the platform does give you is the rest of a sensible launch routine. One-click staging environments let you rehearse a scheduled sale before it touches production. Pre-update safety snapshots and automatic nightly backups mean a launch that goes wrong can be rolled back rather than rebuilt. And if Site Health keeps reporting late events, you can raise it with an Irish-based support team made up of real people, who can verify what is blocking the scheduler on your specific site. All of that is part of Web60's managed WordPress features, included in the €60 a year, with full WordPress and the entire plugin ecosystem rather than a closed builder.

When something else suits better

If your business runs hundreds of subscription renewals an hour, or depends on scheduled jobs firing to the minute around the clock, you are into territory where enterprise managed hosts with dedicated background workers and their own engineering teams genuinely suit the workload better. That is a different class of operation with a different budget. For a shop, a practice or a café scheduling a handful of posts and the occasional sale, it is more than you need.

And if you never schedule anything at all, publishing everything by hand as you go, WP-Cron's lazy timing will rarely matter to you. Run the Site Health check once so updates are not stalling, and move on.

How to Prevent Missed Schedules in Four Steps

Verify the scheduler. Open Tools, then Site Health, and confirm there are no repeated late or failed scheduled events and that the loopback test passes.

Ask the host one question. Find out whether scheduled tasks on your site are run by a server scheduler or only when visitors arrive.

Rehearse in staging. Set up important sales and launches on a staging copy first, and check that the dates behave before you deploy them.

Be present at launch. Log in to your dashboard just before anything with money attached is due to publish, and confirm it is live before sending the email that points to it.

Conclusion

"Missed schedule" is not a mysterious bug. It is WordPress doing exactly what it was designed to do: run scheduled tasks when someone calls by, and catch up later if nobody does. On a busy site that design works quietly. On a small, well-cached site with quiet mornings, it needs a little help.

That help is mostly cheap. A five-minute verification in Site Health. One question to your host. A habit of scheduling the page before the email and being logged in when it matters. Do those, and the next launch you plan for 7am goes out at 7am, while you are putting the kettle on rather than scrambling to work out why the page is still missing.

Frequently Asked Questions

What does "Missed schedule" mean in WordPress?

It means a post or page was set to publish at a specific time, that time has passed, and WordPress has not yet published it. The post is not lost. It is still saved with the Scheduled status and will usually publish the next time the scheduler runs, or you can open it and click Publish yourself.

Why did my scheduled post not publish on time?

WordPress only checks for scheduled tasks when a page on the site is loaded by WordPress itself. If nobody visits in the minutes after the scheduled time, if visitors are being served cached pages, or if something is blocking the site's background requests to itself, the post waits until the next opportunity.

How do I fix a post that shows "Missed schedule"?

Open the post, check the content is final, and click Publish. Then go to Tools, then Site Health, and check for warnings about late or failed scheduled events and failed loopback requests, because one missed post is often a sign that other scheduled tasks are stalling too.

Do WooCommerce scheduled sales start at an exact time?

No. The product editor takes dates rather than times, and WooCommerce starts and ends scheduled sales through a background job that runs once a day around midnight in your site's timezone. If the scheduler stalls overnight, the sale can start or finish late, so verify prices on the morning a sale begins and ends.

Should I install a plugin to fix WP-Cron?

Only if your host cannot set up a server-level scheduler for you. The WordPress handbook's recommended fix is for the server's own task scheduler to trigger WordPress on a fixed interval. A plugin or external ping service can stand in for that, but it adds another dependency to maintain.

Will turning off page caching fix missed schedules?

It might make them less frequent, but it slows every page for every visitor, which costs you far more than a late post. The better fix is a server-level scheduler, or simply being logged in to your dashboard when an important scheduled item is due.

Sources