What WordPress cron is and why it matters #
WordPress runs a scheduling system called WP-Cron that handles time-based background tasks on your site. These include sending scheduled emails, running automated backups, publishing scheduled posts, processing WooCommerce subscription renewals, cleaning up temporary data, and running maintenance routines from plugins and themes. If WP-Cron isn’t working, these tasks pile up or never run at all, and the failures are usually invisible until something obviously breaks.
The unusual thing about WP-Cron is that it’s not a real time-based scheduler. It fires only when someone visits a page on your site. A site with very low traffic may not trigger cron jobs on schedule. A site with WP-Cron explicitly disabled in its configuration, but no server-level cron set up as a replacement, will have cron events that never run at all.
What Loupely captures from cron #
The Loupely WordPress Plugin captures cron state as part of the server-side diagnostic layer:
- Whether any cron events are overdue at the time of capture (scheduled to have run but haven’t)
- How many overdue events are in the queue and how far past their scheduled time they are
- Whether DISABLE_WP_CRON is set to true in wp-config.php
- Whether a loopback request (WordPress’s mechanism for firing cron) is succeeding or failing
- Any PHP Errors that fired during recent cron execution attempts
This data appears in the diagnostic capture when you run a diagnosis on a page of your site. If a cron problem is contributing to the failure you’re investigating (for example, WooCommerce order emails not sending because the email cron is backed up), the correlation rules will connect those signals in the diagnosis.
The 4 cron failure patterns Loupely identifies #
Overdue events with normal traffic #
Cron events are overdue even though the site has regular traffic. This usually means a PHP error is breaking the cron runner before it can complete, a plugin has registered a cron hook that throws a fatal error when it fires, or a long-running cron event is blocking the queue. The triage step points to the specific hook that’s failing based on the PHP error data in the capture.
DISABLE_WP_CRON is true with no server cron replacement #
Some hosting providers or performance guides recommend disabling WP-Cron and replacing it with a server-level cron job. That’s a legitimate optimization, but only if the server-level cron actually gets set up. When the disable flag is set but no replacement exists, cron stops running entirely. Loupely detects this combination and the triage step tells you either how to re-enable WP-Cron or how to set up a server-level cron replacement with your hosting provider.
Loopback request failing #
WordPress fires cron by making a background HTTP request to itself (a loopback request). If your hosting environment blocks loopback requests (some security-hardened configurations do), cron events won’t fire even on a high-traffic site. Loupely detects loopback failures and the triage step routes to your hosting provider support with specific language about what needs to be unblocked.
Overdue events due to low traffic #
The site doesn’t receive enough visits to trigger cron reliably. This is expected behavior for staging sites, development environments, or new sites that haven’t built an audience yet. The triage step for this pattern recommends setting up a server-level cron job (most shared hosting providers support this through cPanel) so that cron fires on a real schedule rather than depending on page visits.