Cron problems never crash a site. Scheduled posts sit on “Missed schedule”, newsletters stop going out, backups quietly don’t happen and WooCommerce orders stay in the wrong status – while every page loads fine and every uptime check stays green. By the time someone notices, the gap is often days long. This guide is about catching that silence early, and the short list of usual suspects once you have.
Why cron fails silently
WP-Cron is not a real scheduler. It runs when someone visits the site: each page load checks for due jobs. On a quiet site jobs run late; with DISABLE_WP_CRON set and no system cron behind it, they never run at all. Action Scheduler – the queue WooCommerce and many plugins use – is triggered through WP-Cron, so when one stops, both stop. None of it produces an error a visitor would ever see.
The early signs
- Overdue events. In WP Crontrol (Tools → Cron Events), events with run times far in the past mean cron isn’t firing.
- Past-due actions. Under Tools → Scheduled Actions, a growing pile of Past-due actions points the same way; a few Failed actions can also hold up the queue behind them.
- “Missed schedule” on posts that should have published.
- Site Health warning that loopback requests fail – the site can’t reach its own
wp-cron.php.
Every one of these requires someone to go and look. The point of monitoring is that nobody has to.
Watch it from the outside: a heartbeat
The most reliable signal is a dead man’s switch. Instead of asking “did anything fail?”, you expect a sign of life on a schedule – and get alerted when it doesn’t come. A heartbeat monitor (in Ravnsight a Pro monitor type) gives you a unique URL to ping. If you run WP-Cron from a real system cron job – the robust setup – let that same job ping the URL after it has run:
*/5 * * * * wget -q -O /dev/null "https://example.com/wp-cron.php?doing_wp_cron" && curl -fsS https://ravnsight.com/hb/YOUR-TOKEN >/dev/nullSet the expected interval a little longer than the cron schedule. If the server’s cron stops, the host comes back from a reboot without it, or wp-cron.php starts failing, the ping stops arriving and you hear about it within minutes – not when Friday’s backup turns out to be missing. The same trick works for any job that must run: a backup script, an import, a nightly sync.
Watch it from the inside: what the site itself reports
A heartbeat tells you the scheduler is alive, not whether the jobs succeed. Inside WordPress, Ravnsight’s Detective plugin watches the scheduler directly: it flags WP-Cron that is broken or far overdue, Action Scheduler queues with failed or past-due actions – naming the hooks behind them, so you see which plugin’s jobs are stuck – and scheduled posts that missed their time.
When the alarm goes off: the usual suspects
DISABLE_WP_CRONwithout a system cron. Someone switched off the traffic-driven cron and never added the replacement. Add a system cron job – or check your host’s panel first; many managed hosts run one for you.- Blocked loopback. A firewall, internal DNS or HTTP authentication on a staging site stops the site from reaching itself.
- One stuck action. A single failing Action Scheduler action can hold up the rest; read the Failed entries first.
- A broken persistent object cache can make scheduling erratic – flush it and watch whether events start running.
Fix what you find, then let the signals confirm it: heartbeat pings arriving on time and past-due actions draining are your proof that cron is back.
