How to disable wp-cron.php in WordPress

WordPress needs to run scheduled tasks in the background: publishing posts at a set time, checking for plugin updates, sending email notifications and running backup jobs. To handle all of this, WordPress ships with a file called wp-cron.php. The problem is that it does not work the way most people assume.

Rather than running on a fixed schedule, wp-cron.php is triggered every time someone visits your site. On a busy site, that means it fires constantly. On a quiet site, scheduled tasks may not run at all if no one visits at the right moment. Neither outcome is ideal, and replacing it with a real server-level cron job is a more reliable approach.

Why the default WordPress cron causes problems

The default behaviour of wp-cron.php has two distinct failure modes depending on your traffic levels.

On high-traffic sites, every page load triggers a check against the cron queue. If multiple visitors arrive at the same time, WordPress may attempt to run the same scheduled task several times simultaneously. This wastes server resources and can cause duplicate actions, such as sending the same notification email more than once.

On low-traffic sites, the opposite happens. If no one visits your site during the window when a task is due, that task simply does not run. A post scheduled for 09:00 may not publish until the next visitor arrives, which could be hours later.

The fix is to disable the built-in WordPress cron and replace it with a proper cron job at the server level, which runs on a genuine time-based schedule regardless of visitor activity.

Step 1: Disable wp-cron.php in WordPress

Open your site’s wp-config.php file. You will find it in the root directory of your WordPress installation. Add the following line before the comment that reads /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

This tells WordPress to stop triggering wp-cron.php on every page load. Scheduled tasks will no longer run automatically until you set up the server-side replacement in the next step.

Step 2: Set up a server cron job to replace it

With the built-in cron disabled, you need to call wp-cron.php directly on a schedule using your server’s cron system. The method depends on your hosting control panel.

Setting up the cron job in cPanel

Log in to cPanel and navigate to Cron Jobs under the Advanced section. Set the frequency to every five minutes, which is the standard interval for WordPress cron tasks. In the command field, enter the following, replacing the path with your actual domain and installation directory:

wget -q -O - https://yourdomain.co.uk/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Alternatively, if your server has PHP available on the command line, you can call the file directly without making an HTTP request:

php /home/username/public_html/wp-cron.php > /dev/null 2>&1

Replace username with your cPanel username and adjust the path if WordPress is installed in a subdirectory. The > /dev/null 2>&1 part suppresses any output so you do not receive a cron email on every run.

Setting up the cron job in Plesk

In Plesk, go to Scheduled Tasks under your domain’s settings. Create a new task and set it to run every five minutes. Use the same wget or php command as above, adjusted for your domain and file path.

If you are unsure how to locate your WordPress installation path in Plesk, the root directory for your domain is typically found under /var/www/vhosts/yourdomain.co.uk/httpdocs/.

Confirming the cron job is working

After setting up the server cron, you can verify that WordPress scheduled tasks are running correctly using a plugin such as WP Crontrol. This shows you all registered cron events, when they last ran and when they are next due. If the timestamps are updating at the expected intervals, the server cron is working.

You can also check your server’s cron logs if you have access to them. Any errors in the command you entered will appear there, which makes it easier to diagnose path or permission issues.

When this change matters most

For most small WordPress sites with moderate traffic, the default wp-cron.php behaviour is tolerable. The case for switching to a server cron job becomes stronger in a few specific situations:

• Your site receives high traffic and you are seeing unnecessary server load from repeated cron triggers.
• Your site is low-traffic and scheduled posts or tasks are not running at the expected time.
• You rely on time-sensitive tasks such as automated backups, WooCommerce order processing or email campaigns.
• You are running a membership site or subscription service where missed background tasks have a direct impact on users.

If any of those apply to your setup, replacing the built-in cron with a server-level job is worth doing. It takes a few minutes and removes a source of unpredictability from your WordPress installation.

For more on keeping your WordPress site running reliably, the WordPress maintenance tasks post covers the regular checks worth building into your routine. If you are also looking at performance more broadly, improving WordPress speed with caching is a good next step.

Disabling the built-in WordPress cron and replacing it with a server-level job gives you predictable, time-based task execution that does not depend on visitor traffic. The change is small but the reliability improvement is real, particularly for sites where background tasks matter.

If you are running WordPress on managed hosting, take a look at our WordPress hosting plans for an environment built to handle this kind of configuration.

If you have questions about setting up cron jobs on your hosting account, the UWH support team is available to help.