WooCommerce cron and stale monitoring: when silence needs attention

A monitoring dashboard can show a reassuring result that is no longer recent enough to trust. If the last store-health report arrived hours ago, its status describes an earlier moment. Freshness is therefore part of the result, not a small detail underneath it.

RevenueGuard shows stale and blocked conditions explicitly. Understanding the difference between missing plugin telemetry and a failing browser journey helps a WooCommerce team investigate the right problem.

Understand the two reporting paths

The WordPress connector sends signed health reports from the store. The hosted service separately runs the configured browser journey. A store can be reachable in a browser while its scheduled reporting is delayed, or it can send telemetry while a particular checkout step fails.

Compare the timestamps for each signal. Do not assume that a fresh browser result makes an old order summary current. Likewise, a recent health report does not prove that a customer can move through the configured checkout.

Know why WordPress scheduling can be delayed

WordPress’s built-in WP-Cron checks for scheduled tasks when page loads trigger it; it is not a continuously running system scheduler. Low traffic or a scheduling configuration problem can therefore affect when tasks execute. WordPress explains this behavior in its Cron documentation.

RevenueGuard’s plugin reports are scheduled at roughly five-minute intervals when WordPress scheduling runs reliably. That is an intended cadence, not a promise of exact delivery every five minutes under all hosting conditions.

Start with the age and the last known change

Note the last received health report, the last completed browser check and the time you first noticed the gap. Review whether the site recently moved hosts, changed its URL, rotated a connection secret, updated security rules or disabled monitoring.

A missing report does not by itself identify the cause. The site may be unable to run the task, unable to send the request or failing authentication. Preserve the message shown in the plugin and avoid repeatedly changing pairing details without a reason.

Check the connection deliberately

In WordPress, open WooCommerce → RevenueGuard and review the configured server and store connection. Use the available health-check action to see whether a manual report succeeds. Keep the connection secret private, including when requesting support.

If manual reporting succeeds but scheduled reports remain delayed, ask the site administrator to inspect scheduling and queued work. If manual reporting fails too, investigate the connection and displayed error. The setup guide lists the pairing requirements and common connection checks.

Treat delayed background work as a signal

WooCommerce stores use background work for different extension and store processes. A delayed-work indicator warrants investigation into which jobs are waiting and why. It does not mean that every pending job is an error or that RevenueGuard can safely run or delete it for you.

Record the relevant job type, age and error with your administrator. Avoid clearing a queue simply to make a warning disappear. The work may represent a business operation that still needs to complete, and the responsible extension’s behavior matters.

Verify both recovery and continued freshness

After a repair, confirm a new health report is received and that later scheduled reports continue arriving. One successful manual send is useful but does not establish that the schedule is fixed. Check the browser journey independently if it also failed or became stale.

Include freshness in the daily dashboard review. When handing over an incident, say exactly which signal is missing. “No plugin report since 10:20” gives the next responder a much better starting point than “the dashboard seems stuck.”