WP-Cron not running: why scheduled posts stop and backups quietly stop happening

WP-Cron is not cron. It is a queue that WordPress checks on page loads, which means a site nobody visits is a site whose scheduled tasks do not run. The post that was meant to publish at 9am publishes when the next visitor arrives — or never, if that is Monday.

The fix is to stop pretending and drive it from a real scheduler. That part is five minutes. The part people skip is proving it stayed fixed.

Replace WP-Cron with real cron, and report success

# In wp-config.php, above "That's all, stop editing":
define( 'DISABLE_WP_CRON', true );

# Then in the server's crontab:
*/5 * * * * curl -fsS -m 20 https://example.com/wp-cron.php?doing_wp_cron >/dev/null \
  && curl -fsS -m 10 https://hb.alertkite.com/p/YOUR_TOKEN

# Check what is queued and whether it is overdue:
wp cron event list --fields=hook,next_run_relative

Setting it up

Set DISABLE_WP_CRON to true so page loads stop triggering it.
Add a server cron entry hitting wp-cron.php every five minutes.
Chain a heartbeat ping onto the end so a failure is reported rather than silent.
Run wp cron event list to confirm nothing is still showing as overdue.

Symptoms that all mean the same thing

Scheduled posts stuck on “Missed schedule”. Backups that stopped without an error. WooCommerce subscription renewals not charging. Update notices that never clear. These look like four separate plugin bugs and are usually one stalled queue.

A caching plugin can hide it

Full-page caching serves visitors without booting WordPress far enough to trigger cron. The busier the cache, the less often cron fires — so the sites with the best caching setups are often the ones where this bites hardest.

DISABLE_WP_CRON alone is not the fix

Setting the constant without adding a real cron entry stops scheduled tasks entirely rather than fixing them. It is a surprisingly common half-migration, and the site gives no indication that anything changed.