wp-cron.php – How To Stop It From Running Frequently

Posted by Bolt Web Hosting on January 23rd, 2012 in Wordpress Optimization.

WordPress is an amazing platform which powers millions of websites. Unfortunately, it can also be extremely inefficient at times – and one particular example is wp-cron.php.

What Is wp-cron.php?

This file is a PHP script which runs all the automated tasks that let WordPress do all it’s wonderful tricks. Some examples include:

  • Posting content when it is scheduled to be posted at specific times
  • Check all pending comments for spam (if you have plugins like Akisment running)
  • Send emails (i.e. if you have the option enabled where you get emailed whenever a comment is posted, this script handles the email)

Basically wp-cron.php is the automatic part of WordPress.

Why Is wp-cron.php Bad?

Wp-cron.php is called every time a page is loaded. That means if you are getting 50 visitors to your site every hour, and each of them reads 2-3 pages, then wp-cron.php is being called:

  • 50 x 2.5 = 125 times per hour
  • 125 x 24 = 3,000 times per day
  • 3,000 x 30 = 90,000 times per month!

It does not just stop there, because unlike other features in WordPress, the wp-cron.php is spawned as an independent process which can sometimes take several minutes to complete its operations. So an active WordPress site with the traffic volume listed above is spawing 3,000 processes every day which do not really do anything.

Wait, You Said wp-cron.php Does Stuff

Yes it does, but if it’s being run every second it becomes redundant, and this is where you have a problem. A script that runs 3,000 times per day is not necessary, and it can put a rather annoying burden on the server, which affects not only you, but everybody else on the server as well.

The only reason you would need the script running that frequently is if you have 10 or more new posts being scheduled to appear every hour on your website (as the scheduler would be guaranteed to run on-time).

If you are a normal user that updates your site only a handful of times every week, then the default setting for wp-cron.php is extremely overkill and it can actually cause performance issues not only for your site, but other sites on the same server.

Think about it this way, supposed there are 100 WordPress blogs on the server (odds are there are many more than that, but for the sake of an example we’ll stick with 100). Those WordPress blogs could potentially be causing 300,000 erroneous processes every day, and 99% of them won’t do anything when they run. As you can probably imagine, 300,000 useless processes running on a server is a huge amount.

But don’t fret, there’s a simple way to being part of the solution, rather than being part of the problem.

How to Tweak wp-cron.php

There is a two-step process that you can do to stop this type of nonsense, which in turns makes your account consume less CPU, which in turn makes the server have a lower load, which in turn makes everybodys websites run faster.
Here’s how it works:

First, you need to stop wp-cron.php from running on every page view. Do this by opening the file wp-config.php (found in the folder where WordPress is installed) and add the following line close to the top of the file:

define(‘DISABLE_WP_CRON’, true);

What that does is tell the WordPress engine not to run the wp-cron.php script on every page view, essentially it disables it.

Second, you need to create a way for the wp-cron.php file to run on a regular basis. Usually the best way to do this is a normal cron job. Create a cron job in cPanel that runs every hour (or less frequently, see below for suggested frequencies), and have the cronjob run this command:

wget -O /dev/null http://www.example.com/wp-cron.php?doing_wp_cron

Change example.com to whatever your domain name is.
That command tells linux to run the wp-cron.php via wget, which works fine and triggers the wp-cron.php script into doing its magic.

All done! You’ve just stopped your website from generating a significant number of processes on the server and it took you a whole five minutes to accomplish! Your web hosting company will thank you, and everybody on the server will appreciate that you are trying to reduce the load you are causing on the server.

Suggested Frequencies

Here is our recommended run times for the cron job if you decide to implement it. This really boils down to two factors:

First – if you are having posts added hourly, then you should set the cron job to run hourly. However this only applies if you are using WordPress’s built-in scheduler to post the content. If you are not using the scheduler at all, then this factor is of no concern to you.

Second – how frequently comments are being left at your blog. If, for example you are getting 1-2 comments per day, then setting the cron job to run every 12 or 24 hours won’t really hurt you at all. Whereas if you are getting 10-20 comments/day, then you might want to look at running the cron job every 2-3 hours. However, if you are constantly getting a lot of comments (and as such, have tools like Akisment and such needing to run frequently), then we suggest running it every 15 minutes.

There is absolutely no reason to have the cron job running more frequently than every 15 minutes.

We strongly recommend you start with running the cron job every 4 or 12 hours and adjust as needed.

Join Us On Facebook

Bolt Web Hosting is on Facebook! Come join us for a chance to win some amazing prizes and be kept updated on our latest announcements.

Bolt Web Hosting on Facebook

Subscribe to Our Newsletter

Signup for our weekly newsletter and get exclusive deals and tips on how to manage your websites effectively.



We respect your email privacy

No comments

No comments yet.

Leave a Comment

All comments are reviewed by one of our staff before they are approved, usually within 24 hours.

Notify: Send me an email when my comment is approved and when anybody replies to it.
Your Comment:

XHTML: You can use these tags:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>