WordPress "Missed schedule" on scheduled posts

What’s actually happening

You set a post to publish at a future time, the time passes, and the post is still sitting there as a draft. In the Posts list the date turns red and reads "Missed schedule." Hit Publish manually and it goes out fine, which proves the content is healthy and the scheduler is the problem. It tends to be intermittent on low-traffic sites because of how WP-Cron actually works.

Common causes

• WP-Cron is traffic-driven, not time-driven. It only runs when someone loads a page, so a site with few visitors can go hours past the publish time before cron fires.
• DISABLE_WP_CRON is set to true in wp-config.php (often added for performance) but no real server cron was set up to replace it, so scheduled events never run.
• Site timezone in Settings > General doesn't match the server clock, so post_date_gmt is computed wrong and the event is queued for the wrong moment in UTC.
• A caching layer or full-page cache serves cached HTML to every request, so wp-cron.php is never triggered by normal page loads.
• A security plugin or firewall blocks loopback requests to /wp-cron.php, so the self-call WordPress makes to itself fails silently.

How to fix it

1. Confirm it's a cron timing problem, not the postOpen the post and click Publish manually. If it publishes cleanly, the content is fine and you're dealing with a scheduler issue. Then install WP Crontrol and look at Tools > Cron Events for a publish_future_post event stuck in the past.
2. Disable WP-Cron and run a real server cronAdd define('DISABLE_WP_CRON', true); to wp-config.php, then add a system cron that hits the file on a schedule. On most hosts: */5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1. Every five minutes is plenty for scheduled posts.
3. Fix the timezone mismatchIn Settings > General pick a named city (e.g. "New York"), not a manual UTC offset. Named zones handle DST; a fixed offset drifts twice a year and shifts your post_date_gmt against server GMT.
4. Unblock the loopback requestIf WP-Cron is still enabled, confirm the server can reach its own URL. Run curl -I https://example.com/wp-cron.php from the host. A timeout or 403 means a firewall, security plugin, or hosts-file/SSL issue is killing the loopback. Whitelist wp-cron.php.
5. Exclude wp-cron from full-page cachingMake sure your cache plugin or CDN isn't caching or rewriting /wp-cron.php. If you switched to server cron in step 2, this stops mattering — that's the more reliable path.