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?


4 Answers 4


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.

  • 2
    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, 2018 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, 2019 at 21:45
  • 1
    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, 2019 at 20:03
  • 5
    @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, 2019 at 3:01
  • 1
    WordPress.org documentation link about this subject changed to developer.wordpress.org/plugins/cron/… Dec 11, 2019 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, 2017 at 17:19
  • 1
    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. Jan 20, 2017 at 18:09

I am yet to find a real downside to offloading wp-cron to external service. Being doing this for many years now.

Especially in todays world where you can run applications as microservices.

I use separate Docker containers for each WordPress component - php, web, db, crontab, redis and so on). Having crontab as separate container, calling wp-cron via http using local network, running only when I need it to.

This reduces stress on backend nodes and improves security by having smaller attack surface.

If the developer can't figure out how to do stuff without having to call wp-cron on every page load, heck, this just speaks for inexperience on his behalf. "Leaving it alone", because you don't understand how things work is not a good reason to keep it.


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.

  • 5
    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. Jan 26, 2020 at 6:03
  • 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
    Jan 26, 2020 at 10:32
  • 4
    if a plugin is coded in a way that totally breaks if wp cron is disabled, then it means it has been programmed by an incompetent, and it's better to immediately uninstall it. Apr 3, 2020 at 20:46
  • 1
    Well, the two comments here prove my point. You have one dev saying "this doesn't disable cron it mearly shuffles it to OS cron" - which is a break in WordPress, which is OS neutral. Then another dev says "hey, it's the responsibility of the plugin dev to plan for the annihilation of wp cron." Uh, ok. So if you want cron functionality, you should PLAN for the elimination of the cron system? To what? The backup cron system? That comment doens't make sense [obviously].
    – John Dee
    Apr 3, 2020 at 23:40
  • Anyway, the current state is "TOTAL CONFUSION". That's the current state. The only solution, from a framwork POV, is to tell people: THERE IS A REASON THE WP-CRON SYSTEM EXISTS. DON'T TURN IT OFF. The other option is 10,000 different, various opinions. Which is what we have now.
    – John Dee
    Apr 3, 2020 at 23:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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