# Why WordPress scheduled posts can publish late on low-traffic sites Default WP-Cron checks for due posts when pages load, so a quiet site may not run the task at its scheduled time. Published: 2026-11-01 Updated: 2026-11-02 Author: Staff Writers Publisher: Digital Publishing News Earlier version reviewed by Shaun Connell, Managing Editor Canonical: https://digitalpublishingnews.com/articles/wordpress-scheduled-posts-cron/ ## A scheduled time is not proof of a published page On a low-traffic WordPress site, a post scheduled for 9:00 may remain unpublished until a later visit triggers the scheduled work. If publication timing matters, check the public article rather than trusting the time shown in the editor. WordPress uses WP-Cron to check and run scheduled tasks. Unlike a continuously running clock service, its standard mechanism is triggered by page loads. A hosting provider can configure an independent system scheduler, but you need to verify that it actually runs and that failures are visible. Source: https://developer.wordpress.org/plugins/cron/ ## Example: a 09:00 post may wait until a 09:17 visit Illustration: an article is due at 09:00, but no request triggers the site’s default WP-Cron check until 09:17. The article can publish late even though the scheduled time was saved correctly. Constantly refreshing the site during testing can conceal this failure by supplying the missing trigger. Check the independent scheduler’s logs before making a test visit. Separate scheduled, executed and publicly observed times Time to record | What a gap suggests --- | --- Scheduled due time | Confirm site timezone and intended date. Scheduler actually ran | A late trigger points toward the scheduling setup. Article became public | A later gap points toward publication or delivery. Newsletter or notification completed | A separate downstream outcome; not proof of publication time. ## Test the host’s scheduler without creating the trigger yourself Schedule a controlled article during a quiet period and ask the host for the scheduler’s execution record. Record the intended time with timezone, when the publish task ran and when the article was first verified publicly. A displayed article date can retain the scheduled time, so it does not prove the page was available then. A public monitoring request can itself trigger default WP-Cron; note when that request occurred and inspect the scheduler evidence before treating it as an independent check. If a task times out, inspect the current article state before retrying. The page may already be published even when the initiating process did not receive confirmation. Repeating an attached newsletter send could create a duplicate. For time-sensitive publication, establish the actual trigger and monitoring with the hosting operator. ## Measure the actual launch time without masking a delay Schedule a test post with a clear expected time and record it before the test begins. Use independent logs to establish whether work ran at that time. If your monitoring request can itself trigger scheduled work, record when that request happened separately. The first observation of a live page might otherwise be mistaken for evidence it went live on time. If late launches recur, compare the host scheduler’s record with the moment the post becomes publicly available. A scheduler may have fired while another step, such as cache invalidation, still delayed visibility. Repeat using a low traffic period and compare the timestamps from the same timezone. The result should tell you which owner has the next action rather than leaving the newsroom to keep refreshing pages. ## Track a scheduled article through three separate clocks Imagine the CMS expects a post at 08:00, a scheduler log records work at 08:01, and a public browser still sees an unavailable page at 08:10. That sequence points to a different investigation from a scheduler that did not run at all. Check cache behavior or deployment status alongside the job result before changing the schedule. Record the expected state, the job result and the first public success as separate fields. If a check request can itself trigger scheduled work, note that request timestamp too. For a newsroom with timed releases, rehearse the full path on a test article before trusting a single green indicator in the admin dashboard. AI production disclosure: https://digitalpublishingnews.com/how-we-use-ai/ ## Sources https://developer.wordpress.org/plugins/cron/ Editorial status: AI-assisted revision; preceding edition reviewed by Shaun Connell. Current revision awaits review.