What is WP-Cron?

WordPress has its own built-in task scheduler called WP-Cron. It handles everything that needs to happen on a schedule: publishing posts at a set time, checking for updates, sending email notifications, clearing database junk, running plugin background tasks. Sounds reasonable, until you realize how it actually works. Unlike a real cron system that runs on a fixed timer, WP-Cron only fires when someone visits your site. No visitors, no cron. And that design decision leads to a whole set of problems.

How WP-Cron Triggers on Page Load

Every time a page is loaded on your WordPress site, WordPress checks a list of scheduled events. If any of them are overdue, it fires them off during that page load. The visitor who triggered the check does not see anything different; the cron tasks run in the background (sort of). But the important thing to understand is: there is no independent process ticking away. The entire scheduling system piggybacks on incoming HTTP traffic.

This was a pragmatic choice. WordPress was designed to run on cheap shared hosting where you cannot install system services or access crontab. The traffic-based approach ensured that scheduled tasks would work out of the box, on any host, without any server configuration.

WP-Cron Problems: Missed Schedules, Performance, and Drift

The traffic-dependent design has obvious problems that become more painful as your site grows, or, paradoxically, when it does not grow enough:

• Low-traffic sites miss their schedule. If your site gets 10 visits a day, scheduled posts might publish hours late. A post set for 8:00 AM will not actually go live until someone visits the site after 8:00 AM, which could be noon if your audience is in a different time zone. WooCommerce order processing, backup schedules, and email digests all suffer the same fate.
• High-traffic sites waste resources. On a busy site, WP-Cron gets triggered on nearly every page load. WordPress checks the event list, evaluates timestamps, and (most of the time) finds nothing to do. That is wasted computation on every request. Worse, multiple simultaneous visitors can trigger the same cron check at the same time, leading to race conditions where the same task runs twice.
• Long-running tasks slow down page loads. When WP-Cron fires, the tasks execute as part of the page request. WordPress tries to spawn a separate background request for the actual cron work, but on some server configurations this fails silently, and the tasks run inline. A backup plugin generating a 500 MB database dump can block a visitor's page load if the loopback connection does not work properly.
• Cron drift accumulates. Because events only run when triggered by traffic, timing is approximate at best. A task scheduled for every hour might run at 1:00, 2:17, 3:02, 4:45, whenever the next visit happens after the scheduled time.

WordPress Tasks That Depend on WP-Cron

You might be surprised how much depends on this system:

• Publishing scheduled posts and pages at their set date and time
• Checking for WordPress core, plugin, and theme updates
• Processing WooCommerce background tasks (order status changes, scheduled sales, stock management)
• Running automated backup plugins (UpdraftPlus, BackWPup, BlogVault)
• Sending scheduled email campaigns or digests
• Cleaning up expired transients, trashed posts, and revision history
• Processing queued tasks from form plugins, membership plugins, and LMS plugins
• Renewing Let's Encrypt SSL certificates (on hosts that handle this via WordPress)

If WP-Cron is unreliable, all of these become unreliable.

How to Replace WP-Cron with a Real Server Cron Job

The standard recommendation for any site that takes scheduling seriously is to disable the traffic-based trigger and replace it with a real system cron job. This is a two-step process:

Step 1: Add this line to your wp-config.php to stop WordPress from triggering cron on every page load:

define('DISABLE_WP_CRON', true);

Step 2: Set up a system cron job to call wp-cron.php on a fixed interval. Most hosting control panels (cPanel, Plesk) have a cron job manager, or you can use crontab -e on a server you control:

# Call WP-Cron every 5 minutes via wget
*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternative using curl
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

# Alternative using WP-CLI (recommended for local calls, avoids HTTP overhead)
*/5 * * * * cd /var/www/html && wp cron event run --due-now >/dev/null 2>&1

The WP-CLI approach is the cleanest because it does not involve an HTTP request. It runs the cron events directly via PHP, which avoids issues with loopback connections, HTTP timeouts, and authentication (e.g., HTTP basic auth on staging sites).

WP-Cron on Managed WordPress Hosting

Many managed WordPress hosts (Kinsta, WP Engine, Cloudways, SiteGround) disable the default WP-Cron behavior and replace it with a server-side cron automatically. If you are on managed hosting, check their documentation; you may not need to do anything. But verify that it is actually working, because some hosts set a very long interval (every 30 minutes or even hourly) that might be too infrequent for your needs.

Is wp-cron.php a Security Risk?

The wp-cron.php file is publicly accessible by default. Visiting it in a browser triggers the cron check manually. While this does not expose sensitive data, it can be abused: an attacker flooding the endpoint with requests can force resource-intensive cron tasks to run repeatedly, creating a denial-of-service condition.

If you have switched to a system cron, there is no reason for wp-cron.php to be publicly reachable. You can block external access via your web server configuration while still allowing the system cron to call it locally.

Debugging WordPress Cron Jobs with WP Crontrol

If scheduled tasks are not running as expected, the WP Crontrol plugin is invaluable. It adds a page to the WordPress admin that shows all registered cron events, their next scheduled run time, and their frequency. You can manually trigger any event, remove stuck events, or add new custom schedules. It is the first tool to install when diagnosing cron problems.

Check Your WP-Cron Configuration with InspectWP

InspectWP checks whether your wp-cron.php file is publicly accessible. If you have moved to a system cron and disabled the built-in WP-Cron, the endpoint should not be reachable from outside. The report helps you confirm that your cron configuration is set up correctly and that you are not leaving an unnecessary endpoint exposed.