How to Disable WP-Cron and Use a Real Cron Job

Two steps, both required: set DISABLE_WP_CRON to stop tasks firing on page loads, then add a system cron job that calls wp-cron.php on a schedule. Doing only the first silently stops every scheduled task on the site.

How WP-Cron actually works

WordPress has no daemon. On each page request it checks whether any scheduled task is due and, if so, fires a second loopback request to wp-cron.php to run it.

The consequences:

• On a quiet site, tasks run late or not at all, because nothing triggers them.
• On a busy site, the check runs constantly and overlapping cron requests consume PHP workers.
• Behind a full-page cache, cached hits may never reach PHP, so cron fires less often than traffic suggests.

A system cron running every five minutes fixes all three cases at once.

Step 1: stop the request-triggered version

In wp-config.php, above the "stop editing" line:

<?php
define('DISABLE_WP_CRON', true);

This only stops the automatic trigger. The schedule itself, and every registered task, stays exactly as it was.

Step 2: schedule it properly

With a system cron (cPanel's Cron Jobs, or crontab -e over SSH):

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

With WP-CLI, which is better because it skips HTTP entirely and reports real errors:

*/5 * * * * cd /path/to/site && wp cron event run --due-now > /dev/null 2>&1

On managed hosting, check the control panel first. Many hosts run a system cron for WordPress already and document how to enable it — in that case both steps may be a single toggle.

Step 3: verify it runs

# What is scheduled, and when it last ran.
wp cron event list

# Anything overdue.
wp cron event list --fields=hook,next_run_relative --status=due

# Run everything due now, and watch for errors.
wp cron event run --due-now

Without SSH, a cron-management plugin shows the same list in the admin. Check it a day after the change: overdue tasks piling up means the replacement is not firing.

Also confirm the practical outcomes rather than trusting the list — schedule a post for five minutes ahead and see whether it publishes, and check that the next backup completes.

Audit what is scheduled while you are here

Disabling WP-Cron is often prompted by slowness, and the real cause is usually one badly behaved task rather than the mechanism.

Look for:

• an analytics or logging plugin running every minute;
• duplicated hooks from a plugin installed twice or migrated between sites;
• tasks left behind by removed plugins, which now fail on every run;
• a heavy task scheduled during peak hours.

Remove an orphaned hook:

wp cron event delete some_removed_plugin_hook

If a plugin re-registers a task you do not want, the plugin is the thing to remove — see how to delete a plugin completely.

What still depends on cron

Before disabling anything, know what stops if the replacement fails:

A store losing its order-email cron is a customer-facing failure, not a background one.

Related performance work

Replacing WP-Cron is a small win on its own. If the goal was a faster site or a faster dashboard, it belongs alongside caching and plugin auditing — see how to speed up a WordPress site and how to speed up a slow WordPress admin.

If tasks stop after the change

1. Check the cron job actually exists and its path is right.
2. Run the command manually from the shell and read the output — silent redirection to /dev/null hides errors, so remove it while testing.
3. Confirm wp-cron.php is reachable and not blocked by a security plugin or a firewall rule.
4. If the site requires HTTP authentication, curl needs credentials.
5. Check Site Health under Tools → Site Health, which reports a missed cron schedule explicitly.