0

TL;DR; Advice please on troubleshooting this issue

I have setup a real CRON scheduler (linux crontab) instead of relying on wp-cron scheduling - further info here. All it does is reliably initiate any due wp-cron actions (wp cron event run --due-now) on and 30 minutes past the hour (0,30 * * * * *). Within those actions is a heartbeat that sends a GET request to an uptime monitoring service (Better Uptime).

The heartbeat is sent successfully 47 times per day, except at exactly 13:00 every day.

A typical CRON output looks like this:

Executed the cron event 'el_trigger_notify_email_when_log_threshold_met' in 0.004s.
Executed the cron event 'wp_privacy_delete_old_export_files' in 0.002s.
Executed the cron event 'my_heartbeat' in 0.148s.
Executed the cron event 'wf_scan_monitor' in 0.003s.
Executed the cron event 'wordfence_hourly_cron' in 0.008s.
Executed the cron event 'wordfence_ls_ntp_cron' in 0.003s.
Success: Executed a total of 6 cron events.

At exactly 13:00 every day, the output look likes this:

Executed the cron event 'wf_scan_monitor' in 0.003s.
{"success":true}

The my_heartbeat action is not executed, the heartbeat is therefore not sent to Better Uptime and Better Uptime in turn reports the failure every day at exactly 13:00 as down time.

I have of course reported this to my hosting provider (SiteGround) and they are saying there are no errors / debug events their side so it must be the website at fault.

How would I even begin to troubleshoot this?

Any advice on how to troubleshoot this, or whether anybody else has experienced this, would be very much appreciated.

David.

2
  • Have you tried setting the cron not to run at the top and bottom of the hour and instead at say 3 minutes past the hour and 33 minutes? Generally, I stay away from top of the hour as many programs execute at that time, both from server side and client plugins etc (even other clients on the server). If you bump it by a few minutes, does it still fail? Maybe SiteGround isn't having an issue but "Better Uptime" might be rejecting the request? Dec 16, 2022 at 20:09
  • Thanks @ConorTreacy, makes sense, I'll give that a try. I suspect that because the wp-cli wp-cron action output doesn't actually include my_heartbeat, I assume it wasn't actually sent, but an avenue for investigation for sure. Maybe my hosting provider logs outgoing requests as well as incoming, that log would include the heartbeat GET request to Better Uptime. Dec 17, 2022 at 15:23

1 Answer 1

1

After further troubleshooting today, and with outstanding support from SiteGround, I have found the root cause. Turns out that every time termly_account_update wp-cron action ran (scheduled every 24 hours), it would crash the wp-cron processes, causing all other due now wp-cron actions to fail, including my my_heartbeat action.

termly_account_update is a wp-cron job associated with the Termly Plugin, a GDPR compliance plugin.

Uninstalling the plugin resolved the problem.

I have reported the bug to the Termly developers.

David.

Your Answer

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

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