WordPress Cron: When To Use System Cron Instead

WordPress includes its own scheduled task system (WP-Cron) that runs maintenance tasks like publishing scheduled posts, checking for updates, and running plugin cron jobs. The system works for most sites but has structural limitations that produce problems under specific conditions.

The conditions where WP-Cron struggles include: sites with low traffic (because WP-Cron runs on page requests), sites where precise scheduling matters, sites with many scheduled tasks. For these cases, replacing WP-Cron with system cron is straightforward and produces better reliability.

How WP-Cron works

WordPress's cron isn't a real scheduled task system. It's piggybacked on visitor traffic. When a visitor requests a page, WordPress checks if any cron tasks are due. If so, it runs them in a background process while the page also gets served.

The strength: no external dependencies. WordPress handles its own scheduling without needing the server to support cron.

The weakness: tasks only run when there's traffic. A site that goes 12 hours without a visitor doesn't run any cron tasks for those 12 hours. Scheduled posts don't publish; emails don't send; updates don't check.

The symptoms of WP-Cron problems

Scheduled posts that publish hours late. The post was scheduled for 8am but didn't actually publish until 10:35am because that's when the first visitor of the morning loaded a page.

Emails that send in batches when traffic arrives. A site sending a daily summary email might send several days' worth all at once when a visitor finally arrives.

Plugin tasks that don't run consistently. Backup plugins, security scans, optimization jobs that should run nightly might skip days or run at unpredictable times.

Tasks that pile up in the cron queue. If WP-Cron can't process tasks as fast as they're scheduled, the queue grows. Eventually it becomes large enough that processing slows down further.

The fix: system cron

The fix is to disable WP-Cron's triggering on page requests and have the server's system cron call WordPress's cron handler on a schedule.

Step 1: disable WP-Cron's page-load triggering. Add to wp-config.php:

define('DISABLE_WP_CRON', true);

This stops WordPress from running cron tasks on page loads.

Step 2: set up a system cron job to call WordPress's cron handler. The crontab entry:

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

This runs every 5 minutes. The wp-cron.php endpoint checks for due tasks and runs them.

For sites where 5 minutes is too granular, use a longer interval (15 minutes, 30 minutes, hourly). For sites where precise timing matters more, use 1-minute intervals.

The hosting consideration

System cron requires the hosting provider to support it. Most VPS, dedicated, and managed WordPress hosting includes cron access. Some shared hosting plans include limited cron access; some don't include it at all.

If your host doesn't support cron, alternatives:

External cron services (EasyCron, cron-job.org) can hit your wp-cron.php URL on schedule. They're free or low-cost and work for sites where the host doesn't provide cron.

GitHub Actions can be configured to run on a schedule and hit your URL. Free for public repos; small cost for private.

UpdraftCentral, ManageWP, MainWP central management tools can trigger cron on schedule across multiple sites.

The verification

After setting up system cron, verify it's working:

1. Wait for the next scheduled cron interval (5-15 minutes depending on your setup).

2. Check the WordPress cron queue. Plugins like WP Crontrol show the queue and last run times. The "next run" times should be in the future; "last run" times should be recent.

3. Schedule a test post for 5-10 minutes in the future. Verify it publishes on time.

4. Monitor for the first 24 hours after setup. Tasks should run consistently.

The plugin tasks consideration

Different plugins handle scheduled tasks differently. Most use WP-Cron's standard mechanism, which works fine with system cron triggering.

Some plugins implement their own scheduling that doesn't go through WP-Cron. For those, the system cron change doesn't directly affect them.

Some plugins have heavy cron tasks that take minutes to complete. If many of these run in the same cron interval, the system cron call might time out before all tasks complete. The remaining tasks pick up on the next interval.

For sites with many or heavy cron tasks: use shorter cron intervals so each interval has less to do. Monitor task durations and adjust intervals to match.

The case where WP-Cron is fine

For sites with consistent traffic spread throughout the day, WP-Cron works fine. The page-request triggering produces reliable cron execution.

Specifically: a site with at least one visitor per hour, 24/7, won't experience meaningful cron delays. Scheduled posts publish reasonably close to their scheduled times. Tasks run on schedule.

For these sites, the system cron migration isn't necessary. The defaults work.

The case where you definitely need system cron

Sites with low or burst traffic. Personal blogs, low-volume B2B sites, sites with traffic concentrated in business hours that go silent overnight.

Sites where scheduled timing is business-critical. News sites where embargoed content must publish at exact times. E-commerce sites where time-sensitive inventory updates matter.

Sites with many scheduled tasks where the queue might back up. Sites running multiple cron-heavy plugins (backups, security scans, performance monitoring, email campaigns).

Sites where you want predictable performance impact. With WP-Cron, the first visitor of a long period bears the cron-processing cost. With system cron, the cost is spread across cron intervals.

The auditing approach

Install WP Crontrol (free plugin) to see what's actually in the cron queue. The plugin shows: each scheduled task, when it last ran, when it's scheduled to run next, what hook it calls.

Review the queue periodically. Tasks that haven't run in days suggest WP-Cron problems. Tasks that are scheduled but no longer needed (from uninstalled plugins) can be removed.

The audit catches both WP-Cron reliability issues and cleanup opportunities. The 5 minutes monthly review prevents accumulation of orphaned cron tasks.

The honest framing

WP-Cron is an acceptable default for sites with consistent traffic. The defaults work for the typical case.

For sites with traffic patterns or scheduling requirements where the defaults don't work, the fix is well-documented and mechanical. The system cron migration takes 15 minutes once you know the steps.

The investment pays off in operational reliability. Scheduled tasks running on schedule. Posts publishing on time. Maintenance jobs running consistently. The reliability compounds across all the scheduled work the site does.

The discipline of monitoring WP-Cron queue health catches problems before they affect users. The five minutes monthly review is a small recurring cost for a real reliability gain.