‘wp_site_health_scheduled_check’ Causes Failure Of Other Scripts

Question

I introduced a heartbeat monitoring system on all my websites late last year. The system involves using a wp-cron action to send a GET request to an API hosted by Better Uptime, triggered by crontab command (wp cron event run --due-now;) every thirty minutes. This works flawlessly on all my websites, except one where every week at exactly 20:30 GMT the heartbeat fails. I have been investigating this.

You can see the pattern for yourself here: https://status.paragondrones.co.uk (open the ‘heartbeat’ section).

Firstly, I checked with Better Uptime. They confirmed that they never received the relevant heartbeats.

Secondly, I checked the wp-cron action timing (a known issue). That was fine.

Thirdly, I checked whether the Termly plugin was the cause (another known problem). It wasn't.

Turning my focus then to Wordpress, and after some lengthy troubleshooting, I discovered that:

• In 60% of cases, there was no crontab log. Probably because Wordpress was too busy to process the crontab command.
• In 40% of cases, a crontab log existed but the heartbeat action was missing from it. Probably because Wordpress was too busy processing scripts because …
• In 100% of cases, the wp-cron action wp_site_health_scheduled_check preceded the failure.

Note: the wp_site_health_scheduled_check action is a standard feature of Wordpress since v5.2.0, one of only two wp-cron actions scheduled to run once per week.

My initial thoughts were that the wp_site_health_scheduled_check script was timing out or trying to utilise too many server resources e.g. RAM, but comparing PHP Variables across three of my websites resulted in no discrepancies – all values were identical. Specifically, max_execution_time, and max_input_time were the same and set to a relatively generous 120 seconds, and memory_limit was set to a generous 768M.

Of course, I could just disable the wp_site_health_scheduled_check action, but this only fixes the issue, not the underlying problem.

I am at a loss now as to what to do or try next.

1. I could try disabling the action, just to prove that it is the root cause, but that doesn’t fix anything.
2. Is there a way to log what wp_site_health_scheduled_check is doing, find out how long it is taking to execute?
3. Should I just arbitrarily increase the PHP limits to see whether that helps?
4. SiteGround, my hosting provider, has two ‘configurations’ of PHP, either ‘Standard’ or ‘Ultra Fast’. I’m not sure what the differences are but is it worthwhile downgrading to ‘Standard’ to see what happens?

This is beyond my knowledge. Any advice/guidance would be warmly received.

David.

Answer 1

First, turn on WP_DEBUG to get a log of the issue. In your wp-config.php you can add something like:

define('WP_DEBUG', true); //record all the errors
define('WP_DEBUG_LOG',__DIR__.'/wp-content/.wp-debug.log'); //you may want to move this to a more secure location (outside of the web root)
define('WP_DEBUG_DISPLAY', false); //don't show errors on the front end

Second, depending on your server setup, the max_execution_time and memory_limit settings may not match what is used by apache/litespeed/nginx/etc when you use the command line. From the command line, try running php -i | grep "max_execution_time" and php -i | grep "memory_limit" to see what those get set to.

Third, I've noticed that wp_site_health_scheduled_check occasionally takes FOREVER to complete (3 to >60 seconds depending on the day). I suspect you are hitting the max_execution_time.

Best of luck!