Looks like WordPress unnecessarily fire WP CRON on every page load. I'm thinking, instead of having it run on every visit, why not just schedule it to run every 5 minutes via server? I could simply trigger wp-cron.php every five minutes and achieve desired result?

Is there any downside to this?


There is no downside for running WP CRON using the server's cron jobs. In fact this is the recommended practice.

According to Official WordPress Plugin Development Document:

WP-Cron does not run continuously, which can be an issue if there are critical tasks that must run on time. There is an easy solution for this. Simply set up your system’s task scheduler to run on the intervals you desire (or at the specific time needed).

To do this, you need to first disable the default cron behaviour in wp-config.php:

define('DISABLE_WP_CRON', true);

Then, schedule wp-cron.php from your server. For Linux, that means:

crontab -e

However, instead of running it in Command Line (CLI), run it as an HTTP request. For that you may use wget:

*/5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cron

WordPress loads all the required core files, Plugins etc. in wp-cron.php with the following CODE:

if ( !defined('ABSPATH') ) {
    /** Set up WordPress environment */
    require_once( dirname( __FILE__ ) . '/wp-load.php' );

So don't worry about WordPress not loading important features.

  • 1
    WordPress.org documentation you linked to mentions wget http://YOUR_SITE_URL/wp-cron.php without the addition of ?doing_wp_cron So is one better than the other? What does the addition of ?doing_wp_cron do that the non-version doesn't? – Garconis Apr 26 '18 at 20:25
  • Probably just so your logs will show the query string so you know how it was called with certainty. – Slbox Apr 12 '19 at 21:45
  • I don't agree with this at all. First of all, it's not true that it's "recommended". Secondly, this method will cripple any plugins that use the actual recommended method of scheduling events. I think this is really bad advice. Almost no one should turn off the cron unless you have a VERY specific reason to do so. The only reason I can think of is if you're breaking WordPress up for a CDN or something. This is NOT normal practice. – John Dee Sep 27 '19 at 20:03
  • @JohnDee: this method doesn't actually disable cron, it disables WP Cron method that checks and attempts to run cron jobs on each page load. define('DISABLE_WP_CRON', true); disables only that part of the cron process and then calling the cron script with code like: */5 * * * * wget -q -O - https://your-domain.com/wp-cron.php?doing_wp_cron on the server makes sure cron jobs are executed. Any scheduling Plugin will not even know the difference. – Fayaz Sep 28 '19 at 3:01
  • 1
    WordPress.org documentation link about this subject changed to developer.wordpress.org/plugins/cron/… – aldemarcalazans Dec 11 '19 at 20:12

There are a couple of downsides: Firstly, when using wp-cron.php as a cli things such as $_SERVER variables aren't set. People overcome this limitation by using a curl request to wp-cron.php instead.

Secondly, Because WP itself isn't loaded with wp-cron.php; if you use a SMTP mailer plugin then this won't be loaded when calling wp-cron. Again, using a curl call overrides this problem. Curl seems to be the most frequently used method.

However; I prefer to use wp-cli after setting mail settings in postfix and (for nginx) php-fpm config correctly and setting a crontab such as

*/5    *   *   *   *  wp cron event list --skip-plugins --skip-themes --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1

(List all crons with specific fields in csv format - hook being the name of the cron, next run relative is the time. Strip out ones showing 'now' as next run (ones due now) using AWK, pass that list to xargs to call wp cron event run $HOOK on each cron. ) Using wp-cli loads WordPress correctly (I choose to skip plugins when listing the crons, as code erros and php warnings will screw up the scripted output; but not to skip them when running the cron with xargs, as the cron may need the plugins being loaded)

Hope this gives you some pointers in what to look out for.

  • 2
    How about setting up: /15 * * * wget -q -O - yourdomain.com/wp-cron.php?doing_wp_cron as suggested by TomMcFarlin - tommcfarlin.com/wordpress-cron-jobs . Seems to do the job well. Would appreciate your comment. – TheBigK Jan 20 '17 at 17:19
  • Yeah as I mentioned throughout people choose to use curl (wget or any other http call) to trigger the crons, and there's nothing wrong with that method. I was just advising the problems of calling the wp-cron php file directly, which wouldn't include the required files, and advising another alternative method if you wanted to spice it up a bit. – TechnicalChaos Jan 20 '17 at 18:09

There are many reasons not to disable the wp-cron. In fact, it's nearly impossible to find a use case to do this. It doesn't slow your site down, and it is used for things you may not be aware of.

Many plugins use the WP-Cron to schedule things. They may become confused if you turn off the scheduler.

There is a proliferation of tutorials on this subject because it is confusing, and because it doesn't do much to your site when you disable it. What it will do, is cause a headache to the dev who has to fix the mysterious problem it creates in six months.

Also, the WP Heartbeat fires every 15 seconds in the admin area, solving this issue for 99% of the people who think they have it.

  • This is a terrible response - they are -NOT- disabling WP Cron. They are merely disabling the invocation of WP Cron on pageload, and offloading it to the system cron daemon instead. Sheesh. – Barry Chapman 20 hours ago
  • Sure, which is a terrible idea for 99.9% of websites. You're changing the architecture of the system for no detectable gain. It's just bad practice. If you're a person reading this [like a CTO], who has discovered WHY changing a system architecture for no appreciable gain in a business setting is a very bad idea - don't worry... You can just hire a developer to perform "code rescue" on your system, and re-engineer whatever the guy you just fired messed up. :) – John Dee 15 hours ago
  • Anyway, the main reason to leave it alone is that many plugins are now using the cron for extended background task running. You can mess up something that the NEXT person is doing, because they expect the system to work in a standard way. Good luck! – John Dee 15 hours ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.