Support » Fixing WordPress » Site Health Not Compatible with Real Cron Job

  • jetxpert


    Hi there,


    define(‘DISABLE_WP_CRON’, false);

    WordPress’ integrated Site Health tool works like a charm.


    define(‘DISABLE_WP_CRON’, true);

    and we’re using a Real Cron Job, the tool does not. We get numerous, varying errors in our Site Health panel (many false positives).

    Any suggestions on how to fix this? Using WP_CRON is not always the best way to run cron jobs for multi-sites or sites with multiple plugins.

    Our System Status (to aid in troubleshooting):

    WordPress Version: 5.2.1
    Server: Apache
    PHP Version: 7.3.6
    MYSQL Version: 5.6.40
    Multisite: No

    Thank you!

Viewing 7 replies - 1 through 7 (of 7 total)
  • JNashHawkins


    That ‘disable wp-cron’ doesn’t have to be run. Nothing says you really have to disable the psuedo-cron to use a ‘real cron’ trigger which is what that does. unless you are concerned about someone triggering cron from outside or DDOS attacks triggering too many psuedo-cron tasks.

    You can also use cron to fire off some tasks provided by some plugins. If that can be done it’s usually documented and is how my multisite with all those aggregators run via Feed WordPress is done.

    And you can try using the wp-cron-control plugin which ‘sabotages’ the psuedo cron and can be set to require a ‘code’ added to the cron task. I’ve not seen any problems with cron tasks being run that way but if you miss a cron task that should have run then I think Site Health may trigger on that. Run a shorter period for cron.

    This slight different plugin can help you determine if you are missing some scheduled cron tasks due to the timimg of your cron and you can run two cron tasks to make sure you are calling every ‘X’ minutes and then once an hour just to make sure nothing is missed. You’ll want your X minutes to be divisible into ‘an hour plus’… ie, ever 11 minutes or every 16 minutes instead of something easily divided into 60 minutes.



    Oh, you can also fire off some cron triggered tasks via WP-CLI!



    @jnashhawkins ,

    Thanks for the input. So, you’re saying we can run WP_CRON and a Real Cron Job simultaneously?


    Dion Designs


    The Site Health check reports what the WP devs think is best. The devs have no knowledge of any individual site or its admin, so the score and recommendations should only be considered as general guidelines.

    In your specific case, if you have found that disabling WP_CRON and using a system CRON task has worked for you, then ignore what is said in Site Health.

    FWIW, I always disable WP_CRON on client sites and set up a system CRON task. I’ve also found that the best server performance/stability/security combination will generate a roughly 65-70% Site Health score. On my personal sites I disable WP’s ability to “call home”, which results in a 35% score, and I’m quite happy with that. 🙂



    If you look at the ‘get’ in the cron task used to fire up the cron in WP you’ll actually see where it calls wp-cron. So you’re substituting a real cron trigger instead of the activity generated trigger.

    wget -q -O - >/dev/null 2>&1

    See it calls wp-cron and passes ‘doing_wp_cron’ to that.

    I also agree with @diondesigns about his take on the Site Health score. Pay attention to it but ‘never argue with success’.



    @jnashhawkins @diondesigns ,

    Thanks, guys. Agreed.

    We decided to deactivate the Site Health Tool with a snippet, disable WP_CRON, and set up a Real Cron Job with a 15′ check interval.

    We lived without the Site Health tool in the past, we can live without it now.


    Moderator Marius L. J.



    So this is an actual issue with the checker it self, you are quite right 🙂

    It’s a bit too strict right now, and we will be loosening up the Cron check, because of it’s nature, it sort of relies on when the cron ran, more so than when it should run right now.

    There’s nothing wrong with replacing the pseudo-cron in WordPress with a real one from your system (it’s actually preferred in many ways, because then you know it’ll run regardless of how active your site is), and although that was taken into consideration, the current implementation does fail now and then when things are actually OK (even for those using the pseudo-cron).

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.