Introduction

When WP-Cron stops running, WordPress can look healthy while important background work quietly piles up. Scheduled posts miss their publish times, cleanup jobs never fire, subscription renewals stall, and plugin automations drift out of sync. The key is to determine whether WordPress never triggered cron at all, or whether the trigger happened but the scheduled work failed downstream.

Symptoms

  • Scheduled posts miss their publish time or stay queued
  • Backups, cleanup tasks, or plugin automations stop running on schedule
  • WooCommerce subscriptions, emails, or follow-up jobs become delayed
  • Site Health reports cron or loopback issues
  • The problem started after moving hosts, enabling cache layers, or changing server jobs

Common Causes

  • DISABLE_WP_CRON is enabled without a working real cron job replacing it
  • Low-traffic sites do not receive enough requests to trigger WP-Cron reliably
  • Loopback requests fail because of firewalls, authentication, DNS, or HTTPS issues
  • A plugin, theme, or long-running task blocks cron execution
  • Server time, PHP path, or cron command configuration changed during migration

Step-by-Step Fix

  1. Check whether WordPress cron is expected to run on page traffic or through a real server cron job.
  2. Review DISABLE_WP_CRON and related configuration so you know whether cron triggering was intentionally changed.
  3. Use Site Health, logs, or cron inspection tools to confirm whether scheduled events are overdue or failing during execution.
  4. Test WordPress loopback behavior to see whether the site can call itself successfully over the expected hostname and protocol.
  5. If using a real cron job, verify its command, PHP binary path, timing, and target URL or script are still valid after recent changes.
  6. Check for plugin, theme, or server errors that cause cron processes to hang, crash, or exceed resource limits.
  7. Clear only the stuck events or conflicting cron hooks after identifying which task is actually blocking the queue.
  8. Retest with a known scheduled action so you can confirm new events execute on time.
  9. Keep cron triggering explicit in your deployment runbook so host changes do not silently break background work.