WordPress Cron: When to Replace WP-Cron with Server Cron

On many WordPress sites, cron problems hide in plain sight. Scheduled posts publish late, update checks happen at odd times, queued emails drift, and background jobs only wake up when someone visits the site. That is because WordPress uses WP-Cron, which is traffic-triggered rather than a true server scheduler. For brochure sites, that may be acceptable. For stores, membership sites, campaign landing pages, and agency-managed client installs, it often is not.

If you care about predictable execution, the practical fix is usually simple: let WordPress keep managing scheduled events, but trigger those events from the server's real scheduler instead of from random page loads. That gives business owners and operations teams a setup that is easier to reason about, easier to test, and less likely to fail quietly.

What WP-Cron Actually Does

WP-Cron is WordPress's built-in task system. Core and plugins use it for update checks, scheduled publishing, cleanup tasks, and other background work. According to the WordPress Plugin Handbook, it checks the queue on page load and runs anything that is due. That means it does not run continuously like Unix cron.

The operational consequence is straightforward: if traffic is low, jobs can run late. If cron spawning over HTTP is unreliable on your stack, jobs can stall even on a busy site. WordPress has improved how cron spawning is handled internally, but it is still not the same thing as having the operating system call a task on schedule.

When A Real Server Cron Is Worth It

Moving to server cron is usually worth doing when timing matters or when missed jobs have a business cost. Typical cases include scheduled publishing, WooCommerce or subscription workflows, feed imports, cache warming, backups, cleanup jobs, and client sites where support tickets are expensive.

You do not need to over-engineer this. A small content site may be fine with the default setup. But if your team has ever had to ask, Why did this scheduled task not run? you are already at the point where a real scheduler is the safer choice.

The Safe Way To Change It

The official WordPress guidance is to disable page-load cron spawning and let the system task scheduler call WordPress instead. The required config change is:

define( 'DISABLE_WP_CRON', true );

Add that to wp-config.php, then create one reliable scheduler entry on the server. Do not disable WP-Cron first and forget the second step, or scheduled events will stop running.

Option 1: Use A Standard HTTP Request

The WordPress handbook shows calling wp-cron.php from the system scheduler. On Linux, a simple pattern is:

*/5 * * * * wget --delete-after --quiet https://example.com/wp-cron.php >/dev/null 2>&1

This is easy to understand and close to the official documentation. It works well when the site is publicly reachable and you do not have authentication, firewall, or reverse-proxy rules interfering with the request.

Option 2: Use WP-CLI For More Control

If you already manage WordPress with WP-CLI, a CLI-driven cron is often the cleaner operational choice. It avoids relying on a web request to wp-cron.php and gives your team a direct command to test and log.

*/5 * * * * cd /var/www/example.com && wp cron event run --due-now --path=/var/www/example.com >/dev/null 2>&1

That command runs all due cron events. On multisite, add --url= for the target site. If WP-CLI is not in the cron user's path, use the full binary path instead of just wp.

Which interval should you use? Five minutes is a sensible default for many business sites. One minute may be justified for stores, membership systems, or time-sensitive automations. Fifteen minutes is often enough for simple marketing sites. The right choice is operational, not ideological: set it to match the business cost of delay.

How To Test The Setup After You Switch

Do not treat cron as set-and-forget. Verify it immediately.

wp cron test
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence
wp cron event run --due-now

wp cron test is useful because it checks whether WP-Cron spawning is disabled, whether alternate cron mode is set, and whether WordPress can successfully spawn cron over HTTP. The event list command gives a quick view of what is scheduled and when it is expected to run next. Running due events manually is the fastest way to confirm that the queue is actually moving.

Common Mistakes

The most common error is disabling WP-Cron without creating the replacement job. The second is assuming a host-level cron exists when no one has checked. The third is using a cron user that cannot access the WordPress files, environment, or correct PHP and WP-CLI binary.

Another frequent issue is choosing the wrong trigger method for the stack. If the site sits behind access rules, basic auth, strict firewall rules, or a proxy setup that interferes with requests to wp-cron.php, the HTTP method may be fragile. In those cases, WP-CLI is usually easier to diagnose and support.

For agency teams, this matters because cron failures rarely stay isolated. They surface as missed publishes, stale feeds, delayed automations, or client complaints that are expensive to trace back later. A small infrastructure cleanup here often removes a disproportionate amount of operational noise.

A Better Default For Managed Sites

If a WordPress site supports a real business process, it is sensible to treat scheduled tasks as infrastructure, not as a best-effort feature. Keep WordPress's scheduling system, but give it a predictable trigger, test it, and document who owns it. That is usually enough to turn a flaky background process into a stable one.

If your WordPress stack needs cleaner scheduling, fewer silent failures, and someone to own the operational details, Greg can help put the right cron setup in place without overcomplicating the stack.

Need help with this kind of work?

If your WordPress stack needs a more reliable cron setup, Greg can audit it and put a cleaner operational process in place. Get in touch with Greg.

Sources

Last modified

2026-04-24