WordPress Cron Monitoring: The Silent Failure Uptime Checks Miss

Here’s a scenario that catches even experienced agencies off guard: uptime monitoring shows green across the board, the site loads fine for every visitor, and yet the last successful backup was three weeks ago. Nothing looks wrong from the outside because nothing actually is wrong from the outside — the front end never depended on the thing that’s broken. wp-cron quietly stopped firing, and every scheduled task riding on it has been silently failing ever since.

Table of contents

• Why this is invisible to standard monitoring
• How heartbeat monitoring catches it
• What usually causes a missed heartbeat
• FAQ
• A scenario this actually caught

Why this is invisible to standard monitoring

WordPress’s own wp-cron is what quietly drives scheduled backups, security scans, and a long list of other maintenance tasks in the background. It’s also, by design, triggered by page visits rather than a true system-level scheduler — which means a host blocking outbound requests, a fatal PHP error somewhere in the chain, or a misconfigured server can silently break it while the site itself keeps serving every visitor a perfectly normal page. An uptime check measures exactly that — can a visitor reach the site — and by definition has no way to see a failure that never touches the front end at all.

How heartbeat monitoring catches it

The WP Warden plugin installed on each site sends a regular heartbeat to the backend through the site’s own wp-cron mechanism. If that heartbeat stops arriving, heartbeat monitoring flags it immediately — a genuinely independent signal from HTTP uptime checks, catching a failure category that standard monitoring structurally cannot see, no matter how frequently it runs.

What usually causes a missed heartbeat

In practice, it’s rarely a dramatic failure — usually one of a handful of quiet, unglamorous causes: a hosting provider changing its outbound request policy without announcing it, a caching layer interfering with cron’s own request cycle, or a plugin conflict that throws a fatal error specifically during the cron process while leaving the rest of the site untouched. None of these show up in a visitor’s browser. All of them show up here.

A scenario this actually caught

A site’s hosting provider quietly rolled out a change restricting outbound requests, as part of an unrelated security hardening update on their end. Nothing about the site itself changed, and nothing a visitor could see was affected — the front end kept responding exactly as before. What changed, invisibly, was that scheduled backups stopped completing entirely. Heartbeat monitoring flagged the missed check within a day; without it, the first sign of trouble would have been discovering a three-week gap in backup history at the exact moment a backup was actually needed.

FAQ

Isn’t this the same as uptime monitoring?

No — a site can respond completely normally to visitors while its cron is entirely broken underneath. This is a structurally different check catching a different, invisible-from-the-outside failure mode.

What usually causes a missed heartbeat?

A hosting-level change to outbound request handling, a fatal PHP error somewhere in the cron chain, or the site’s own wp-cron being disabled somewhere in its configuration.

Start a free 14-day trial — no credit card required.

← Back to the Blog