When WordPress marks a post Missed Schedule, the publish time passed and the post did not go live. WordPress usually runs scheduled work through wp-cron, which triggers when someone (or something) loads the site. On a quiet site, or when page cache, DISABLE_WP_CRON, or a host rule blocks those triggers, scheduled posts can sit unpublished until you notice.
Work this checklist in order. Prefer staging when you can reproduce a scheduled publish there. Take a backup before changing cron settings or cache rules on production. This article is about scheduler / wp-cron failures. If the editor fails while you press Publish now, use publishing failed / invalid server response. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix. We confirm the scope before work begins.
Define what failed
- Confirm Posts (or a custom post type) shows Missed schedule after the planned time, not a draft you never scheduled.
- Note whether the site gets regular visits, and whether other scheduled tasks (plugin cleanup, backups) also stall.
- If the whole site is offline when the post should have published, check site down first.
- If Publish now fails in the editor with an invalid server response, use publishing failed instead of this checklist.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| Missed schedule on a low-traffic site | Too few visits to trigger scheduled work on time. | Site Health for cron warnings; visit the front end once and recheck |
DISABLE_WP_CRON is true; no system cron | Cron disabled without replacement | Ask host for a real system cron hitting wp-cron.php |
| Heavy page cache / CDN; cron still overdue | Cached responses skip PHP | Exclude the cron URL; confirm uncached hits reach WordPress |
| Started after a plugin or host change | Conflict or blocked loopback | Staging isolation; ask host about loopback / cron blocks |
| Manual “Run” of overdue events works | The tested event runs; automatic triggering needs checking. | Check regular triggers and host cron logs. |
Safe diagnostic order
- Confirm the schedule and the Missed Schedule state. Open the post in Admin, note the planned time and timezone, and that status shows Missed schedule (or equivalent). Publish once manually only if you accept going live immediately; otherwise leave it for testing on staging.
- Check Site Health and overdue cron events. In Tools → Site Health, look for cron-related warnings. Use a trusted cron manager plugin or your host’s WordPress tools to list overdue events. If many events are overdue, the trigger path is a useful next check.
- Control test: trigger cron once. On staging (or with host guidance on production), visit the front end without full-page cache, or call
wp-cron.php the way your host documents. If overdue scheduled posts then publish, the queue can run when PHP is reached; focus on traffic, cache, or a system cron.
- Look for
DISABLE_WP_CRON. In wp-config.php (backup first), see whether DISABLE_WP_CRON is set to true. If it is, WordPress will not run cron on page loads. Ask your host to add a real system cron that hits wp-cron.php on a short interval they support, or remove the define only when you understand the traffic impact. Prefer the host’s documented method over random snippets.
- Check whether caching prevents cron triggers. If visits are served entirely from cache, they may not reach WordPress to trigger scheduled work. Ask your host to confirm that requests to
wp-cron.php bypass caching and reach WordPress. If the site relies on cached pages, ask the host to verify a separate scheduled cron job is running. Retest a future post on staging.
- Ask about loopback and host blocks. Some hosts block WordPress from calling itself (loopback) or rate-limit
wp-cron.php. Open a host ticket with the Missed Schedule times and any Site Health cron warning. A system cron that hits wp-cron.php over HTTP(S) from the host’s scheduler is a common fix when they approve it.
- Isolate plugin conflicts on staging. If misses started after a plugin change, disable the newest non-essential plugin briefly and schedule a short test post. See plugin not working when isolation points at one product. Restore protection and required plugins after the test.
- Retest with a future schedule. On staging, schedule a post a few minutes ahead, keep a path that reaches PHP (or rely on the system cron), wait past the time, and confirm it publishes without Missed schedule. Restore any temporary plugin changes. Keep durable cron or cache exclusions that fixed the problem.
Common causes
- Low traffic so
wp-cron rarely or never runs.
DISABLE_WP_CRON enabled without a working system cron replacement.- Page cache or CDN serving static HTML so PHP (and cron) never runs on visits.
- Host blocking loopback requests or limiting
wp-cron.php.
- Plugin conflicts stalling or flooding the cron queue.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help on one WordPress site clearing repeatable Missed Schedule failures: confirming whether wp-cron is triggering, coordinating a host-approved system cron or cache exclusion, and verifying a future scheduled post publishes on time. Paste when posts were scheduled, when you saw Missed schedule, and whether the site gets regular visits. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, custom editorial calendars, multi-site fleets, and editor “invalid server response” failures while clicking Publish now are outside this offer. Use publishing failed for editor/REST publish errors and site down when the site is unreachable at publish time.
Related checks
If Site Health, a control cron trigger, and host-confirmed system cron or cache exclusions still leave Missed schedule, send your host the planned publish times, the Missed Schedule timestamps, Site Health cron warnings, and whether DISABLE_WP_CRON is set. Suspected compromise needs a security investigation as well as restoring reliable scheduling.