WordPress Cron: When It’s Time to Replace WP-Cron with Server Cron

By Greg Nowak. Last updated 2026-07-10.

WP-Cron is fine until a site starts depending on timing. A scheduled article appears late, an import waits for the next visitor, or a renewal task drifts into a support ticket. At that point the problem is not that WordPress has a scheduler. It is that the scheduler is being woken by web traffic while the business expects clock-based reliability.

For most established WordPress sites, the sensible change is smaller than it sounds: keep WordPress’s event queue, but replace the traffic-dependent trigger with the server’s scheduler. That makes scheduled work more predictable without forcing plugins or editors to adopt a new system.

What changes when you move to server cron

WordPress core and plugins register events in WP-Cron. On normal site requests, WordPress checks for due events and attempts to spawn wp-cron.php. If the site has no traffic, a due event can sit until the next request. A busy site creates more opportunities to trigger the queue, but it can still have trouble if loopback HTTP requests are blocked or unreliable.

A server cron job supplies the dependable wake-up call. WordPress still decides which hooks are due and runs them. This distinction matters: server cron improves the trigger, but it does not repair a slow import, a broken plugin callback, or a task that was never scheduled correctly.

Do you actually need to replace the default trigger?

The decision is about the cost of delay, not site size. A low-traffic membership site may need dependable scheduling more than a busy publication where a five-minute delay changes nothing.

A safe migration sequence

1. Inventory the important jobs. Record the hooks or business workflows that matter, their expected frequency, and who notices when they fail.
2. Choose an interval. Five minutes is a sound starting point for many business sites. Use one minute only where the workflow justifies it; use 15 minutes where timing is relaxed.
3. Create the server job. Prefer WP-CLI when you control the server. Use an HTTP call when that is what the hosting platform supports.
4. Run the exact command manually. Test it as the same operating-system user, with the same paths and permissions the scheduler will use.
5. Then disable page-load spawning. Add the following setting to wp-config.php only after the replacement trigger works.

define( 'DISABLE_WP_CRON', true );

Reversing that order creates an avoidable outage: events remain scheduled, but nothing wakes the queue.

Choose the trigger that fits the hosting setup

WP-CLI: the cleaner option on a managed server

WP-CLI avoids the public web path and gives the technical team a command it can run directly. Use absolute paths because cron often has a smaller environment and a different PATH from an interactive shell.

*/5 * * * * /usr/local/bin/wp cron event run --due-now --path=/var/www/example.com

Change both paths for the real server. On multisite, add --url=https://example.com to select the intended site. During commissioning, keep command output available; once the job is stable, route output and errors into the logging or alerting system your host actually monitors.

HTTP: useful when the platform schedules URL calls

An HTTP trigger is simpler on hosting without a dependable WP-CLI setup. The WordPress handbook uses wget to request wp-cron.php:

*/5 * * * * /usr/bin/wget --delete-after --quiet https://example.com/wp-cron.php

Confirm the request works from the server itself. Basic authentication, firewall rules, redirects, CDN policies, or a security plugin can block a request that looks fine in a browser. The --quiet flag suppresses output, so remove it while testing or make sure the scheduler records failures elsewhere.

Test the replacement path, not the old one

Before the switch, wp cron test is useful for diagnosing WordPress’s built-in HTTP spawning system. After DISABLE_WP_CRON is set to true, that command is expected to report an error because the spawning system is deliberately disabled. It is not a valid health check for the new server job.

Use WP-CLI to inspect the queue and run due events directly:

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

Then run the full scheduled command as the cron user. Check that it exits successfully, due events execute, and their next-run times advance. Finally, test one real low-risk workflow, such as a scheduled draft or a non-customer-facing import. A healthy queue is useful evidence; a completed business workflow is better evidence.

Make it supportable after launch

• Document the scheduler, system user, command, interval, WordPress path, and site URL.
• Assign an owner for failures and decide where errors should be visible.
• Avoid leaving both page-load and server triggers active after commissioning.
• Review long-running or repeatedly failing hooks separately; a faster trigger will not fix their code.
• Keep a rollback note: restore the normal WP-Cron setting if the external scheduler becomes unavailable.

Replacing the WP-Cron trigger is a small infrastructure change, but it crosses WordPress, hosting, permissions, and business process. If those boundaries are creating recurring support work, Greg can audit the queue, implement the right trigger, and leave your team with a setup it can understand and operate. Talk to Greg about your WordPress operations.

Related on GrN.dk

• WordPress Security Releases Still Need an Ops Runbook for Business Sites
• AI Crawler Control for Business Websites: Protect Content Without Sacrificing Search Visibility
• Critical CSS for Faster Pages: When It Helps and When It Does Not

Need help with this kind of work?

Talk to Greg about WordPress operations Get in touch with Greg.

Sources

• Cron – WordPress Plugin Handbook
• Hooking WP-Cron Into the System Task Scheduler
• wp cron event run – WP-CLI Command
• wp cron event list – WP-CLI Command
• wp cron test – WP-CLI Command