Why WordPress scheduled posts can publish late
Pressing Schedule in the editor adds a task to a list. According to the official WordPress Plugin Handbook, WP-Cron handles scheduled tasks, including publishing scheduled posts, and in its default form it checks that list on each page load rather than running continuously.
The handbook illustrates the consequence with a task set for 2:00PM on a site that receives no page loads until 5:00PM, and warns that scheduling errors could occur in that situation. Missed tasks are queued and run at the next page load, so a delay of that kind fits the mechanism: nothing prompts the task until a page load arrives.
On a default set-up, a post that appears late after a quiet period matches that documented behaviour. A post that stays unpublished after your test needs closer investigation, because a failed test alone does not establish the cause.
Which sites feel the delay most
Sites with few visitors leave longer gaps between page loads. In the handbook’s example, no page loads occur between a task’s scheduled time of 2:00PM and a later visit at 5:00PM. A launch or newsletter that depends on timely publishing needs a trigger that does not rely on the next visitor arriving.
A different risk applies where DISABLE_WP_CRON is set to true in wp-config.php. In the configuration the handbook describes, that setting is added after a system task has been scheduled to request wp-cron.php, and it turns off the default page-load trigger. As a consequence of switching that trigger off, a site with the constant set but no working system task has nothing left to prompt its scheduled tasks.
Caching and other hosting layers differ between providers. The handbook describes the trigger as a page load, and whether a cached page served by your hosting reaches WordPress at all is a detail only the host can confirm for your account.
A careful test for scheduled publishing
A temporary post lets you observe publishing on the site you want to check, but on a live site the test post becomes public once it publishes. On a typical site it shows on the blog, can appear in the site's feeds and can be picked up by crawlers, and publication can set off anything connected to new posts, such as newsletter, social sharing or other auto-publish plugins. A neutral title, paused connections and prompt deletion keep that exposure small.
A staging copy only avoids public exposure if its outgoing connections and visibility are contained first, since a copy can keep live credentials and scheduled work. Even when contained, a staging copy checks only its own scheduler and configuration, so its result does not establish whether live publishing works.
The test below includes page loads after the scheduled time because a page load is the documented prompt for the default scheduler. Reloading Posts > All Posts in the dashboard is itself a page load, so the front-page visit and the list reload are both prompts, and the test cannot tell you which one ran the task. The one-minute waits are practical suggestions for this check rather than documented figures.
- Confirm that no newsletter, social sharing or other auto-publish connection will send out the test post, and pause any that would.
- Create a post with a neutral title such as Scheduling check, set its publish time a few minutes ahead and press Schedule. Write down the exact scheduled time.
- Once that time has passed, load a page on the front of the site and note the time. Wait about a minute, then open or reload Posts > All Posts and record the status the post shows.
- If the post still shows as scheduled, reload the Posts list once more after another minute before treating the result as a failure.
- Open wp-config.php and search for DISABLE_WP_CRON. Note whether the line is present and what value it has.
- Delete the test post straight away, then open the Bin view (shown as Trash on some sites) in the Posts list and choose Delete Permanently so the post does not linger. Switch back on anything you paused and keep your notes for the next step.
What your test result tells you
An on-time post is an observed outcome, not proof of its cause. Your own visits during the test, including the Posts list reload, each counted as a page load that could prompt the default scheduler. A pass therefore shows that publishing worked while you were actively loading pages, and leaves open how the site behaves during quiet hours, whether any server task ran, and how the rest of its scheduled jobs are getting on.
Your host is the right contact for the server side, and one message covering everything saves a round of back and forth. Send the scheduled time, the times you loaded a page and checked, the status the post showed, and the DISABLE_WP_CRON value you found. Then ask how scheduled tasks are triggered on your account, whether cached pages reach WordPress, and, where DISABLE_WP_CRON is set to true, whether a server task requests wp-cron.php at a regular interval along with that job's execution or request result around your test time.
Even a server record of that request only shows the request was made. Whether every task WP-Cron then ran completed successfully is a separate question, which is why concrete times and results matter: they give the host something to trace and keep the conversation away from guesses.
Checking DISABLE_WP_CRON in wp-config.php
WordPress keeps core settings in wp-config.php, in the main folder of the installation. You can open it through your host's File Manager or an SFTP client. Download a copy before you edit anything, so the original can go back if the site stops loading.
In the handbook’s configuration, DISABLE_WP_CRON set to true switches off the page-load trigger. A missing line does not settle how the scheduler is configured, since your host can manage scheduling outside that one file. Leave any change to the host or a developer if you are unfamiliar with the file.
Page-load trigger or host scheduler
The default page-load trigger needs no set-up. Its timing depends on page loads reaching the site, which suits content where a delay after a quiet spell causes no harm. Launches, sale pages and announcements tied to a fixed time are a poorer fit.
For critical tasks that must run on time, the Plugin Handbook describes hooking WP-Cron into the system task scheduler as an easy solution. The server requests wp-cron.php at set intervals, and the handbook gives crontab and wget examples for Linux and macOS, plus a PowerShell approach for Windows. Hosting providers differ in which method their accounts support and whether a control panel screen exists for scheduled jobs.
The wget example requests wp-cron.php over the web, so the request needs to reach WordPress for the approach to work. Your hosting set-up decides whether that example fits or a different method is needed.
When you switch, set up the host scheduler and confirm the job's request results with the host before DISABLE_WP_CRON is set to true in wp-config.php, because switching off the page-load trigger first leaves scheduled tasks without a prompt in the meantime. If you run your own server, our server set-up guide includes a cron checklist row.
Getting help with scheduled publishing
Server questions start with the host: whether a scheduled job exists, what its results show and how it reaches WordPress. If the host confirms that requests arrive and your test still fails, give a developer the times and results you recorded so they can investigate further.
BugShield offers one-off fixes at a confirmed price if you would rather hand that investigation over, and Shield maintenance plans include bug fix requests for ongoing care. Either way, a repeat test post is a simple way to recheck publishing after hosting changes.
Sources
WordPress missed scheduled posts FAQs
Why did my scheduled post publish hours after its set time?
One documented explanation is the way default WP-Cron waits for page loads. The WordPress Plugin Handbook gives an example of a 2:00PM task with no page load until 5:00PM and warns that scheduling errors could occur. That explanation does not establish why every delayed post failed to appear, so record your test results and share them with your host if the behaviour remains unexplained.
Does a post publishing on time prove my server cron job works?
No. A page load that reaches WordPress triggers the default scheduler, and your own visits during the test, including reloading the Posts list, count as page loads, so an on-time post does not identify which request ran the task. The host can supply the job's execution or request result at your test time.
When is it safe to set DISABLE_WP_CRON to true?
The Plugin Handbook says to add DISABLE_WP_CRON after the system task that requests wp-cron.php has been scheduled. As our own extra precaution, confirm the job's results with your host before you set it, because the setting removes the page-load trigger.
Will a scheduled test post be visible to the public?
Yes, on a live site. On a typical site it shows on the blog once published, can appear in the site's feeds and can be picked up by crawlers, and connected newsletter or social sharing plugins can send it out. Use a neutral title, pause those connections, then delete the post and remove it from the Bin with Delete Permanently.
What should I send my host if a test post does not publish?
Send the scheduled time, the times you loaded a page and checked the post, the status shown under Posts > All Posts, and whether DISABLE_WP_CRON appears in wp-config.php with its value. Ask how scheduled tasks are triggered on your account, whether cached pages reach WordPress, and for any scheduled job results around that time.