How Does WP-Cron Actually Work Behind the Scenes?

How WP-Cron Actually Fires

WordPress stores a list of scheduled tasks (events) with their next-run times in the database, and on every page load, a small script checks whether any due event needs to run, executing it inline as part of handling that request if so. This design avoids requiring true server-level cron access, which made WordPress easier to run on basic shared hosting historically, but it fundamentally ties task execution to actual site traffic rather than true, independent time-based scheduling.

Where This Becomes a Real Limitation

• Very low-traffic sites may go extended periods without a page visit, meaning scheduled tasks (order-related background jobs, subscription renewals, cleanup routines) can be significantly delayed simply because nothing triggered the check.
• A caching plugin serving fully static pages for anonymous visitors can bypass the WP-Cron check entirely for those requests, since the check happens in PHP execution that a fully cached response skips.
• Running scheduled tasks inline with a regular page request can add noticeable delay to that specific page load if the task itself is time-consuming, a subtle performance consideration some site owners don't realize.
• Disabling WP-Cron's default behavior (via DISABLE_WP_CRON) and replacing it with a genuine server-level cron job calling wp-cron.php on a fixed schedule addresses both reliability and the inline-delay issue.

Setting Up Reliable Scheduling

1. For any site with real scheduled task dependencies (WooCommerce especially), set DISABLE_WP_CRON to true and configure a genuine server-level cron job instead.
2. Set the server cron job's frequency (typically every 5-15 minutes) to match how promptly scheduled tasks need to run.
3. Verify scheduled tasks are actually running on time via WooCommerce → Status → Scheduled Actions or a similar tool.

Need reliable scheduled task processing set up properly? See WordPress bug fix.