WP-Cron vs System Cron

April 27, 2026

Easy

Medium

How WordPress Handles Scheduled Tasks

WordPress has a built-in task scheduler called WP-Cron. It handles things like publishing scheduled posts, checking for updates, sending email digests, and running maintenance routines. Unlike a traditional cron system, WP-Cron does not run on a clock — it runs whenever someone visits your site.

Mochyon Lightspeed detects this automatically. It checks whether WP-Cron is running in its default mode and flags the extra overhead on every page load.

How WP-Cron Works

On every page load, WordPress checks if any scheduled tasks are due. If they are, it fires an HTTP request back to itself (a “loopback” request) to process those tasks. This loopback request includes the full overhead of a DNS lookup, TCP connection, and TLS handshake — essentially a second page load happening in the background of every visitor request.

On a busy site, this means hundreds of redundant loopback checks per hour. On a low-traffic site, it means scheduled tasks might not run for hours or days if nobody visits.

What System Cron Does Differently

A system cron job (sometimes called a “real” cron) runs on a fixed schedule set at the server level, completely independent of site traffic. Instead of checking on every page load, it triggers WordPress’s task runner at a predictable interval — typically every five or fifteen minutes.

The benefits are straightforward:

No loopback overhead — page loads no longer trigger an extra HTTP request, removing DNS, TCP, and TLS overhead from every visit
Reliable timing — tasks run on schedule regardless of traffic volume, which matters for things like scheduled posts or automated reports
Reduced load — instead of checking on every page view, the scheduler runs at a fixed interval you control

When This Matters Most

The overhead of WP-Cron’s loopback request is typically 50–200 ms per page load, depending on the server’s DNS resolution speed and whether it can reach itself quickly. On fast-hosting setups with local loopback, the impact is smaller. On shared hosting or servers behind a CDN, the loopback can be slower because the request may route through external infrastructure before reaching the same server.

Sites running WooCommerce, membership plugins, or email marketing integrations tend to accumulate many scheduled tasks, making the per-request check more expensive.

How to Tell Which Mode You Are Using

If your wp-config.php file contains define('DISABLE_WP_CRON', true);, the default loopback mode is off — which means either a system cron is configured, or scheduled tasks are not running at all. Without that constant, WordPress is using the default loopback mode on every page load.

Setting DISABLE_WP_CRON without actually configuring a system cron job is a common misconfiguration. In that case, no scheduled tasks run at all — scheduled posts never publish, plugin update checks never fire, and transient cleanup stops. If you see that constant in your config, verify that a cron entry like */15 * * * * curl -s https://example.com/wp-cron.php (or equivalent) is actually set up on the server.

Most managed WordPress hosts set up system cron automatically. If you are on shared or unmanaged hosting, check with your provider or look for cron job settings in your hosting control panel.