Missed WP-Cron Events: Diagnosing Stuck Hooks and Recovering Jobs

In WordPress, "missed cron" is not noise - it means a known event that should have run more than 24 hours ago simply did not. Each missed event is a lost feature: a backup that was not created, an email that was not sent, a sync that did not happen. As stuck hooks pile up, the site looks fine but is in fact only partly working.

Why this matters

WordPress relies on cron for nearly every background task: wp_version_check that detects core updates, publish_future_post that publishes scheduled posts, wp_scheduled_delete that empties the trash, plus plugin hooks such as action_scheduler_run_queue from WooCommerce, wpseo_onpage_fetch from Yoast, or updraft_backup from UpdraftPlus. When an event is more than a day late it does not run "soon" - it stacks with additional events and in most cases WP-Cron gives up and stops trying. The visible effect: WooCommerce does not update order statuses, Yoast does not crawl broken links, UpdraftPlus does not back up - and you do not learn about it until you need that backup.

How to detect

The definitive method is WP-CLI:

wp cron event list --format=table --fields=hook,next_run_relative,next_run_gmt

Any hook whose next_run_relative is significantly negative (for example -2 days) is stuck. Visual alternative: install the free WP Crontrol plugin and visit Tools > Cron Events. It highlights overdue hooks in red. RankPlus itself scans for hooks whose next_run is older than time() - 86400.

How to fix

1. Manually run everything that is overdue: wp cron event run --due-now. This forces immediate execution and bypasses the loopback HTTP step that often fails.
2. If that errors out, enable WP_DEBUG_LOG in wp-config.php and inspect wp-content/debug.log. The fatal will name the plugin that kills the loop.
3. If a particular hook is stuck and should not run anymore (for example, a remnant of a deleted plugin), remove it: wp cron event delete <hook>.
4. Fix the root cause: on low-traffic sites WP-Cron will never trigger naturally. Switch to system cron - see the wp_cron_status check for the full walkthrough.
5. Inspect the doing_cron transient - if it is stale, see the doing_cron_stale check.

Common mistakes

• Hitting wp-cron.php in the browser: this does not always work because WordPress holds a transient lock. Running through WP-CLI is far more reliable.
• Deleting hooks without identifying their owner: a hook with an unfamiliar name may belong to an active critical plugin. Confirm with wp cron event list which plugin registered it before deleting.
• Trusting an external trigger without verification: cron-job.org or EasyCron can stop silently if the server blocks their User-Agent or requires Basic Auth.
• WP_CRON_LOCK_TIMEOUT set wrong: too low and two cron processes run in parallel attempting the same task. The default (60) is usually correct.

Verifying the fix

Run wp cron event list again - every next_run_relative should be in the future. Wait 5-15 minutes and verify that missed_scheduled_posts clear, that the next backup runs on time, and that pending emails go out. In RankPlus the status returns to green on the next scan cycle.