How to Disable wp-cron Running in the Background

To keep your blog running smoothly, WordPress often needs to schedule tasks to run at certain times, or at some point in the future. Examples include scheduling posts for publication at a future date, generating backups and newsletters at regular intervals.

In order to make this happen, WordPress has an internal feature called wp-cron. In order to make WordPress easy to install, a nasty hack is used to execute wp-cron every time a visitor hits your site, or you do anything on the dashboard.

There are several problems with this:

  • It increases the load on your server, especially if you have a lot of visitors

  • It's erratic, especially if you have few visitors or use a caching plugin like W3-Total-Cache

  • There's a bug that can cause it to execute multiple times in parallel, leading to annoying problems such as duplicate MailPress newsletters
  • It's a hack

Notice that problems occur both if you have too many visitors, and if you have too few. And you should be using a caching plugin. All this is bad news.

For these reasons, I recommend you disable background execution of wp-cron by WordPress, and set up a real cron job in you host's control panel to execute wp-cron at regular, predictable intervals. To do this, start by adding this to your wp-config.php:

/* Disable evil background wp-cron */
define('DISABLE_WP_CRON', true);

Then you need to create a real cron job to run wp-cron at regular intervals. On CPanel hosting services like HostGator, log in to your CPanel. Under the Advanced section at the bottom, click the icon labelled Cron jobs. Make sure the Cron email address is set correctly to your email address.

Add a new cron job, selecting Common Settings: Twice a day. If you know your blog needs finer scheduling then you can increase this to Once an hour say, but otherwise twice a day should be plenty.

Specify the command as:

/usr/bin/php -f /home/username/public_html/wp-cron.php >/dev/null

Replace username with your username. Initially you might want to leave off the >/dev/null bit so you can see the output and check that it looks OK. I don't recommend redirecting the error output by adding 2>&1, because if there are errors you want to know about them.

If you're on IX Web Hosting, note that Cron is under FTP -> FTP Manager -> FTP User -> Crontab and you'll probably have to include a path to the PHP config file you use to increase the PHP memory_limit. So it'll look more like this all on one line:

 -c /hsphere/local/home/username/
 -f /hsphere/local/home/username/ >/dev/null

If you happen to have enabled WordPress's multisite feature, which is unlikely if you're just creating a personal or small-business blog for yourself, read disabling multisite wp-cron.

And you're done! We now return you to your regularly scheduled wp-cron task.

If you want to know more, here are some other articles I found helpful about disabling background wp-cron:

Run WordPress tasks from real cron job
How to disable WordPress wp-cron

Liked this post? Subscribe to get more like it via email.

About Graham

I'm the creator of
This entry was posted in Problems and tagged . Bookmark the permalink.

27 Responses to How to Disable wp-cron Running in the Background

  1. Aaron says:

    Hi Graham,

    I am having a problem with woocommerce sometimes sending approximately 6 or 7 emails at a time. I have a feeling this might be to do with WP Cron - would you know for sure?

    If I have around 12k visits to my site each month, will WP Cron be having a considerably negative effect on site performance? In other words, will it be noticably faster and use noticably less resources if changing to manual cron jobs?

    Lastly, what time interval would you recommend we set for triggering manual cron jobs - about every 15 minutes? Or more/less frequently?


    • Graham says:

      I doubt it will make much difference if you've got 12k visits/month, but it may fix the email problem. Give it a try! I run mine once an hour, and that's enough for me. Cheers, Graham

  2. Sara - My Merry Messy Life says:

    Hi Graham, great article. I'm having a lot of trouble with CPU throttling (then my site crashes) when I get a huge spike in traffic - could this be one of the reasons why it's crashing (I'm on WordPress)? I also deleted 2 plugins that were hogging load time. A friend of mine told me to try this, too, but had a different command than your's.

    php -q /home/publier9/public_html/pieceofmind/wp-cron.php

  3. Dan says:

    Thanks for this excellent write-up Graham.

    One question:

    What's the


    in the command line stand for?

  4. I came across your post as I was trying to set this up on IXWebHosting.

    I've copied-and-pasted exactly what you have here in the final field (changing my username and domain name, of course). I'm not certain it's running, though. How can I check it? Schedule a post for a few minutes from now, and then see if it posts the next time the cron job is supposed to run?

  5. Rigette says:

    Exactly what I need to solve my problem. Just a note about your site - the pop-up about liking the post on facebook and twitter can sometimes be annoying and I have to wait for around 20+ seconds before I could read your post. I hope you can do something about this, maybe lessening the time:)

  6. Grady says:

    Thanks for this post. Simple yet practical. I forwarded this to a friend that was being overrun by cron jobs and it was easy for them to implement. I think I'll do a post and link back to this one if you don't mind.

  7. I did what you suggest, but through the advice of my host. I disabled cron in the wp-config.php, set up a cron job in Control Panel, and set it to run once every 6 hours. When it ran, it brought my site down.

    So, my question is, can I just leave it disabled and not run it at all? We post about 5 articles at most a week, although comments run higher. I don't know of anything that is scheduled. So can I just leave wp cron disabled and not set up a cron to run it at all?

    I'm using WP Super Cache, and all my plugins seem to be working fine when wp cron isn't running. Thank you!

    • Graham says:

      The main thing that will break if you disable wp-cron altogether is scheduled posting. Some backup plugins also rely on scheduling. If you don't rely on these feature it might not be such a problem, but I wouldn't recommend disabling it altogether. Better to look into why running a cron job brings your site down; that shouldn't happen! Cheers, Graham

      • Thank you!

        That helps a lot. I found that I can run that cron command, but I have to use curl instead of the php command. Apparently that is how my host, Lunarpages, is set. I tested and got the email cron had run.

        Also, found a cool plugin called WP-Cron. It's shows all the scheduled cron jobs. Mine calls updates for the theme, wp, and a few plugins, and has "execute tasks" for a few other specific plugins, and it shows the times they are scheduled for.

        Lunarpages has asked me to set the cron to run wp-cron every 4-12 hours. That seems like it should work well. Hopefully this will help keep my CPU down.

        You might put in the article, that if the php cron doesn't run or throws errors, people might be able to run cron using curl instead:

        curl /home/username/public_html/wp-cron.php >/dev/null

        Thank you! This article was super helpful, as was your comment.

  8. I am now implementing this fix. One the username my blog admin username, or my cpanel username. I would think the blog admin name, but thought I would check to be sure. Thanks for your help.


    • Graham says:

      What you really want is the full path to your public_html directory on your hosting provider; your cpanel username is usually part of that. So no, it's not your blog admin name.

      If you're implementing this to workaround the problem of multiple MailPress newsletters, note that WordPress 3.3 has recently been released and it is supposed to fix the bug that causes the problem. So there's less need to disable background wp-cron once you upgrade to 3.3.

      Cheers, Graham

  9. LD Jackson says:

    Okay, I discovered I had disabled wp-cron in the wrong wp-config file. My blog is located in a sub-folder of public html, instead of public html itself. Trouble is, when I insert the code to disable wp-cron in the correct file, my blog will not load. It just gives me a blank page. Any idea what could be going wrong?

  10. LD Jackson says:

    Okay, I may have figured out what was going on, but I have one more question. If I disable wp-cron from running in the background and set up a cron job to run wp-cron at regular intervals, do I still need to choose wp-cron to send batches in the Mailpress settings, or do I need to choose other?

  11. LD Jackson says:

    Because I am still having a problem with Mailpress sending out duplicate batches, I would be interested in knowing how to apply the patch EJ mentioned above. Does it require a lot of coding skills?

    • Graham says:

      You shouldn't need the patch if you follow the instructions to disable wp-cron from running in the background and run it from a real cron job; unless something else is going wrong to generate the duplicate batches. Applying the patch would require some programming skills. However, it will be included in WordPress 3.3, which I expect will be released within the next few weeks; it is currently in its second beta test.

      • LD Jackson says:

        That's the problem, Graham. I have followed your instructions to disable wp-cron and have created a cron job from cPanel to run the batch, but it still sends out duplicate batches. It doesn't happen every time, maybe every other post, but it does still happen.

        Here is the cron job I created.

        php -q "/home1/gdjackso/public_html/mytake/wp-content/plugins/mailpress/mp-content/xtras/mp_batch_send/cron.php" >/dev/null 2>&1

        • OnePack says:

          This is probably not because cron is fired 2 times but because the sending of the batch failed. When you have batches of 10 addresses maybe 5 users got the newsletter and the other 5 didn't. When you set retry to 1 (or two perhaps) the newsletter module will process the batch that failed again and so 5 will get the newsletter two times and the other 5 just one time. A solution is to make your batches smaller.

  12. EJ says:

    I wanted to bring this recent bugfix to your attention. This should improve cron locking and (hopefully) prevent duplication, although I have not yet tested it personally, and have no data right now on what impact it will have on Mailpress performance or wp-cron reliability.

    Regardless, I do encourage you to patch one of your WordPress deployments that relies heavily upon Mailpress, with this fix, and post your results. This would require switching away from invoking CPanel / linux server administered 'cron tabbing' back to WordPress' internal wp-cron hooks. I would be personally interested in your observations regarding the impact of this bugfix, as I'm sure would your readers.

    The added benefit is that, if you find (via this patch) wp-cron to be reliable again under various Mailpress test cases (low and high mail server load, variable batch levels, etc.), it could reduce the steps in configuring Mailpress, effectively streamlining the process you've outlined even further.

    Finally, this probably goes without saying, but if you do decide to research this, please don't test this on your production blog; if you have a test server use that, and if you do not, provision one! Great post and blog Graham.

    Good hunting and regards. Please feel free to email me personally as well if you'd like to discuss ideas.


Comments are closed.