--- title: "How to fix \"Missed schedule\" on a scheduled WordPress post" url: https://wpministry.co/errors/missed-schedule/ description: "The post's time passed and WordPress did not publish it. WordPress runs scheduled tasks only when a page loads and the site can reach itself." lang: en-US --- Skip to content # How to fix "Missed schedule" on a scheduled WordPress post The post's time passed and WordPress did not publish it. The post is intact. Publish it now, then find the reason. WordPress only runs scheduled tasks when a page is loaded and the site can send a request to itself, and one line in wp-config.php switches that off. By WP Ministry Published October 7, 2026 Tested on WordPress 7.1.4, PHP 8.3.36 ## In short - "Missed schedule" means the post's time has passed and it is still scheduled. Nothing is lost. - WordPress publishes a scheduled post only when a page is loaded after its time and the site can request its own wp-cron.php. - `wp cron event run --due-now` publishes what is waiting. A post it leaves behind can be published by its ID. - A DISABLE_WP_CRON line in wp-config.php stops scheduled publishing unless a cron job on the server runs the tasks instead. - `wp cron test`, or Tools then Site Health, shows whether the site can reach itself. - A cron job on the server puts publishing on a real clock. "Missed schedule" appears on the Posts screen, in the Date column, where a scheduled post said "Scheduled". It means the time you set has passed and the post is still waiting. The task that should have published it did not run. Nothing is lost. The post is as you left it, and it keeps the date you gave it when it is published late. ## How a scheduled post gets published When you schedule a post, WordPress adds a one-off task for it, named `publish_future_post`, to its own scheduler, WP-Cron. WP-Cron is not a clock. WordPress's handbook says it "is only triggered on page load": when a page is requested, WordPress looks for tasks that are due and, if it finds one, sends a request to its own `wp-cron.php` file, which runs them. So a post goes out on time only when three things hold. A page is loaded after the post's time. WP-Cron has not been switched off. The site can send that request to itself. The first fix publishes what is waiting, whatever the cause. The others each deal with one of the three. The commands are WP-CLI, run over SSH from the folder WordPress is installed in. How to use WP-CLI (https://wpministry.co/blog/use-wp-cli-manage-wordpress/) covers connecting and installing it, and in the WP-CLI command builder (https://wpministry.co/tools/wp-cli-command-builder/) you choose a job, fill in what it needs, and copy the command with its flags in place. ## Where it goes wrong A page request passes through each of these in turn. This one comes from **WordPress itself**. 1. Browser 2. DNS 3. HTTPS 4. CDN or firewall 5. Web server 6. PHP 7. WordPress (this error comes from here) 8. Database and files ## What causes it - ### WP-Cron is switched off in wp-config.php and nothing runs in its place Common The line that sets DISABLE_WP_CRON to true stops WordPress starting its scheduled tasks on page loads. It is meant to go with a cron job on the server. Without one, nothing scheduled runs. Fix: Publish the missed posts now, or Turn WP-Cron back on, or Put the scheduler on the server's clock - ### The site cannot send a request to itself Common WordPress starts its scheduled tasks by requesting its own wp-cron.php over HTTP. When the server, a firewall or a password on the site refuses that request, the tasks never start. Fix: Publish the missed posts now, or Test whether the site can reach itself, or Start the tasks without that request, or Put the scheduler on the server's clock - ### Nobody loaded a page when the post was due Sometimes WP-Cron is only triggered by a page load. A post due at 2:00 on a site whose next page load is at 5:00 is published at 5:00. A page answered from a stored copy, without WordPress running, does not count. Fix: Publish the missed posts now, or Put the scheduler on the server's clock - ### The task that would publish the post is no longer in the queue Rare WordPress takes a task off its list just before it runs it. If that run is cut short, the post stays scheduled and nothing is left to publish it. Fix: Publish the missed posts now ## How to fix it ### Publish the missed posts now - Easy - No risk - About 5 minutes - Steps tested on WordPress 7.1.4 Without WP-CLI, go to Posts, choose "Quick Edit" under the post's title, set "Status" to "Published" and press "Update". Do the same for each post marked "Missed schedule". 1. #### Step 1: List the posts that are still scheduled The dates are in the site's own timezone. A date in the past is a missed post. bash Copy ``` wp post list --post_status=future --fields=ID,post_title,post_date ``` 2. #### Step 2: Run every task that is due This runs each task whose time has passed, not only posts, and prints a line for each, such as "Executed the cron event 'publish_future_post'". It works while WP-Cron is switched off. Newer versions of WP-CLI answer "A cron event run is already in progress; skipping." when WordPress tried to start its tasks within the last minute. If yours does, go on to the next step. bash Copy ``` wp cron event run --due-now ``` 3. #### Step 3: Publish what is still listed Run the list again. A post still there with a past date has no task left to publish it. Publish it by its ID, here 123. Several IDs can follow one another. WordPress answers "Success: Updated post 123." A post whose date is still ahead stays scheduled, even if you name it. bash Copy ``` wp post update 123 --post_status=publish ``` ### Turn WP-Cron back on - Easy - Back up first - About 10 minutes - Steps tested on WordPress 7.1.4 1. #### Step 1: Read the setting `true` means WordPress has been told not to start scheduled tasks on page loads. An error saying the constant is not defined means it is not set, and this fix is not yours. Without WP-CLI, open `wp-config.php` and look for `define( 'DISABLE_WP_CRON', true );`. bash Copy ``` wp config get DISABLE_WP_CRON --format=json ``` 2. #### Step 2: Find out whether anything runs the tasks instead The line is meant to be paired with a cron job on the server. `crontab -l` over SSH lists yours. One can also be set in a hosting control panel, so look there or ask the host. If there is one and posts are still missed, the job is failing: see the last fix. If there is none, go on. 3. #### Step 3: Remove the line bash Copy ``` wp config delete DISABLE_WP_CRON ``` 4. #### Step 4: Load any page of the site The missed posts are published within a few seconds. Reload the Posts screen and the Date column says "Published". **To undo it:** Put the line back in wp-config.php. ### Test whether the site can reach itself - Takes care - Back up first - About 15 minutes - Steps tested on WordPress 7.1.4 Without WP-CLI, go to Tools, then Site Health. "Your site could not complete a loopback request" (https://wpministry.co/errors/could-not-complete-a-loopback-request/) means the request WordPress sends to itself failed, and the text under it gives the error. A pass there is not proof that scheduled tasks start: the test sends your login with its request, and the request that starts scheduled tasks does not. Site Health also reports "A scheduled event is late" when tasks are not running on time, which is one reason the maintenance checklist (https://wpministry.co/blog/wordpress-maintenance-checklist/) has you read it every month. 1. #### Step 1: Run the test "Success: WP-Cron spawning is working as expected." means the request got through, and this is not your cause. bash Copy ``` wp cron test ``` 2. #### Step 2: Read the error - "The DISABLE_WP_CRON constant is set to true. WP-Cron spawning is disabled." Use the fix above. - "WP-Cron spawn returned HTTP status code: 403 Forbidden". Something understood the request and refused it. - The same line with 401. The site is behind a password, as a staging copy may be. WordPress sends no password with this request. - "WP-Cron spawn failed with error:" and a cURL error. The request never arrived. Error 6 means the server could not find the site's own domain name, 7 that it could not connect, and 28 that no answer came in time. These are for the host. 3. #### Step 3: For a 403 on Apache, look for a rule that names the file Each line it prints names `wp-cron.php`. Copy `.htaccess` somewhere safe, then remove the rule that denies access to the file, together with any `` lines that open and close it. If nothing is printed, the refusal comes from a firewall or from the host: ask for the server's own requests to `wp-cron.php` to be let through. bash Copy ``` grep -n -i "wp-cron" .htaccess ``` 4. #### Step 4: Test again, then wait a minute and load a page When `wp cron test` reports success, wait a minute before loading a page. WordPress does not start its tasks more than once in 60 seconds, and a failed attempt counts. The missed posts are then published. **To undo it:** Put back the lines you removed from .htaccess. ### Start the tasks without that request - Easy - Back up first - About 10 minutes - Steps tested on WordPress 7.1.4 If you cannot remove what refuses the request, WordPress has a second way to start its tasks. Its documentation gives it for scheduled posts that are not being published. WordPress sends the visitor's browser a redirect to the same page and runs the tasks in the connection the browser has just left. 1. #### Step 1: Add the line above "That's all, stop editing" wp-config.php Copy ``` define( 'ALTERNATE_WP_CRON', true ); ``` 2. #### Step 2: Wait a minute, then load a page The address gains `?doing_wp_cron=` and a number for that one request. The missed posts are published. A visitor sees that address whenever a task is due, and WordPress's documentation says the method carries some risk. Use it where a cron job is not open to you. **To undo it:** Remove the line from wp-config.php. ### Put the scheduler on the server's clock - Advanced - Low risk - About 20 minutes The handbook's answer for tasks that must run on time is to have the server's scheduler, cron, run them at a fixed interval, whether or not anyone visits. This crontab line runs the command from the first fix every five minutes, so a post is at most five minutes late. Change both paths to yours. text ``` */5 * * * * /usr/local/bin/wp cron event run --due-now --path=/home/example/public_html --quiet ``` The command makes no web request, so whatever refuses `wp-cron.php` is not in its way. Once the job is in place, set `DISABLE_WP_CRON` to true so that page loads stop trying to start the same tasks. The guide to automatic backups (https://wpministry.co/blog/schedule-automatic-wordpress-backups/) has the whole procedure under "Put WP-Cron on a real clock": opening the crontab, a line for servers without WP-CLI, the order to do it in and how to check that it works. **To undo it:** Remove the line from wp-config.php first, then the line from the crontab. ## When to get help If posts are still missed after `wp cron test` reports success, or it reports a connection error on a server you do not run yourself, what is left is the server's own logs and firewall. Past that point, more changes inside WordPress are guesses. ## Common questions Does a post published late keep the date I scheduled? Yes. Publishing changes the post's status and leaves its date alone, so it carries the day and time you set, not the moment it went out. Can the Timezone setting cause it? Not by being wrong. A post scheduled under the wrong timezone is published at the wrong hour, and until then the Posts screen says "Scheduled". Changing the timezone afterwards is different. The label is worked out from the post's local time and the timezone the site has now, while the publishing task keeps the moment it was given when the post was saved. After a change under Settings, General, "Timezone", a post can say "Missed schedule" hours before its task is due. Open the post, set its date again and save it. Why was the post published as soon as I looked? Opening the Posts screen is a page load like any other. On a quiet site, WordPress finds the task due as you look at the list and publishes the post a moment later. Posts on such a site go out late, not never, and a cron job on the server puts them on time. ## More on this subject - WordPress errors and troubleshooting: https://wpministry.co/topics/wordpress-troubleshooting/ - Guide WordPress uptime monitoring: what a check sees and what it misses: https://wpministry.co/blog/wordpress-uptime-monitoring/ - Guide How to update the PHP version of a WordPress site: https://wpministry.co/blog/update-php-version-wordpress/ - Glossary term wp-config.php: https://wpministry.co/glossary/wp-config-php/ - Glossary term WP-Cron: https://wpministry.co/glossary/wp-cron/ - Guide admin-ajax.php high CPU usage in WordPress: how to find what is calling it: https://wpministry.co/blog/admin-ajax-high-cpu-wordpress/ - Glossary term Database table prefix: https://wpministry.co/glossary/database-table-prefix/ ## Would you rather we fixed it? Quick Fix is $49. One issue, one site, up to about an hour. No fix, no fee. 30-day warranty. More about this work: One-time WordPress fix (https://wpministry.co/services/one-time-fix/) May we measure how this site is used? A yes notes the pages of this visit and loads Google Analytics. A no keeps and loads nothing. See the cookies page (https://wpministry.co/legal/cookies/). If you say yes, we note the pages you look at during this visit and load Google Analytics. If you say no, nothing is kept and nothing is loaded. The site works the same either way. The cookies page (https://wpministry.co/legal/cookies/) has the details. ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://wpministry.co/#organization", "name": "WP Ministry", "url": "https://wpministry.co/", "logo": "https://wpministry.co/brand/logo.png", "address": { "@type": "PostalAddress", "streetAddress": "1309 Coffeen Ave STE 1200", "addressLocality": "Sheridan", "addressRegion": "WY", "postalCode": "82801", "addressCountry": "US" }, "sameAs": [ "https://www.linkedin.com/company/wp-ministry/", "https://x.com/wpministryco", "https://www.instagram.com/wpministryco/", "https://www.facebook.com/wpministryco", "https://www.tiktok.com/@wpministryco", "https://www.pinterest.com/wpministryco/", "https://www.youtube.com/channel/UCOZRuAukk5QSTRPG6BaHl3Q" ] }, { "@type": "WebSite", "@id": "https://wpministry.co/#website", "name": "WP Ministry", "url": "https://wpministry.co/", "inLanguage": "en-US", "publisher": { "@id": "https://wpministry.co/#organization" } }, { "@type": "TechArticle", "@id": "https://wpministry.co/errors/missed-schedule/#article", "headline": "How to fix \"Missed schedule\" on a scheduled WordPress post", "description": "The post's time passed and WordPress did not publish it. WordPress runs scheduled tasks only when a page loads and the site can reach itself.", "url": "https://wpministry.co/errors/missed-schedule/", "mainEntityOfPage": "https://wpministry.co/errors/missed-schedule/", "inLanguage": "en-US", "image": "https://wpministry.co/og/errors/missed-schedule.png", "author": { "@id": "https://wpministry.co/#organization" }, "publisher": { "@id": "https://wpministry.co/#organization" }, "datePublished": "2026-10-07T00:00:00.000Z", "dateModified": "2026-10-07T00:00:00.000Z" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://wpministry.co/" }, { "@type": "ListItem", "position": 2, "name": "Error fixes", "item": "https://wpministry.co/errors/" }, { "@type": "ListItem", "position": 3, "name": "How to fix \"Missed schedule\" on a scheduled WordPress post" } ] } ] } ```