WordPress missed schedule: find the failed stage before adding a plugin

A scheduled post remains unpublished after its intended time. Before installing a “missed schedule” plugin, establish whether the problem is the saved date, the scheduled event, the mechanism that runs due events or the public page visitors receive. Those failures need different fixes.

This is a diagnosis method for site owners and maintainers. The sample IDs and times are illustrative. It does not report a fresh test of your site’s scheduler or authorise running production jobs as an experiment.

Why saving a future date is not the whole process

WordPress uses WP-Cron for time-based work, including scheduled posts. In its default model, checks are triggered by page loads rather than by a continuously running clock. A due task can therefore run later when no request triggers the check at the intended time. WordPress explains the default WP-Cron model.

That is one possible cause, not a diagnosis of every late article. A site may already have a hosting scheduler, and a job may run without producing the intended public result. First identify how this installation is configured.

Capture a small evidence card

• Post ID and title.
• Stored status and scheduled publication time.
• WordPress site timezone, including whether it is a city timezone or fixed UTC offset.
• Expected public URL.
• Relevant scheduled event and the post ID attached to it.
• Runner type: default request-triggered WP-Cron or an independently configured scheduler.
• Observed public response and the time checked.

A useful hypothetical record says: “Post 8123, future, due at 09:00 in the configured site timezone; at 09:07 it is still future.” It does not say only “cron broken.” Avoid silently converting between the editor’s local display and UTC when comparing timestamps.

Distinguish four failure stages

1. Wrong saved time. The publication is not due according to the stored timestamp. Compare the actual site timezone and the intended instant. Correct the individual record deliberately; do not change every site’s timezone to solve one misunderstanding.
2. Missing publication event. The post is future, but the corresponding publication event is absent. Inspect the creation path and scheduling plugins. A missing event is a different problem from an event nobody has run.
3. Due event not processed. The event exists and is overdue. Check scheduler configuration, invocation logs and errors before adding another runner.
4. Published record, stale public view. The post is publish, but a visitor sees an old archive, cached response or inaccessible URL. Investigate that public path separately.

WordPress’s publication handler is invoked by the publish_future_post event and checks that the post has future status. Core handler reference. This connects the event to a specific publication without assuming that every scheduled task belongs to the blog.

List events without running all of them

Where an authorised maintainer has WP-CLI access, the following inspection command lists publication events. Run it against the intended WordPress installation:

wp cron event list --hook=publish_future_post --fields=hook,next_run_gmt,args --format=table

Read the event arguments to find the relevant post ID and compare the GMT time correctly. This is an event inventory, not proof that an invocation succeeded. WP-CLI event-list reference.

Do not use “run every due event” as a harmless test. The same queue can contain emails, commerce actions and plugin maintenance. For an existing customer site, the investigation should begin with inspection and approved recovery for the affected record.

Use a hosting scheduler when traffic-independent timing is required

If the site relies on visitor-triggered checks and needs more predictable timing, the host can configure a scheduler to invoke WordPress cron. WordPress documents this arrangement and the configuration used to stop request-triggered spawning. Official system-scheduler guide.

Have the maintainer identify the installation, runtime, interval and log destination. Verify the replacement runner before disabling the existing trigger. A configured cron entry without execution evidence does not establish that the correct site is being processed.

The interval is also a timing tolerance. In an illustrative five-minute schedule, a task becoming due just after a run may wait almost five minutes for the next check, plus execution time. This is not an exact-second publication promise. Queues, failures and caching can add delay.

Recover the affected post and verify the public result

Once the cause is understood, agree whether the late post should publish now or at a new time. Preserve its intended identity and record the decision. A manually published article resolves that record; it does not prove the recurring scheduler is repaired.

For ongoing verification, use a designated non-customer test environment or an agreed real publication. Confirm the saved status, public canonical URL, article visibility and any archive cache. Then check the next intended scheduler run. Keep the result scoped to the evidence you observed.

For a site-specific repair, describe the missed time, affected URL and available hosting access in an enquiry about custom development. A useful handover identifies both the failure and the recovery, rather than merely reporting that a plugin was installed.

Sources and preparation

• WordPress: WP-Cron
• WordPress: system task scheduler
• WP-CLI: list scheduled events
• WordPress: publish_future_post handler

Prepared with AI assistance using official documentation consulted on 23 October 2026. Examples are illustrative; no customer test or human approval is claimed. For corrections, use the author’s profile.

Illustrative cover photograph: Towfiqu barbhuiya / Unsplash.

About the author

Martin Iliev

Martin builds Set It Once to help people spend less time on repeated work. His guides explain what you can try, how to check the result and where the limits are.

More about Martin

All articles