The schedule is only as good as the background worker that runs it. This page shows how to prove the worker actually executes — in about two minutes.
Where to Look #
The worker health card appears on both:
- GravityOps → Recurring Submissions → Settings
- GravityOps → Recurring Submissions → Queue (top of the screen)
Queue also shows the worker’s state as one of its summary cards.
The Four Readings #
| Reading | Question it answers | What healthy looks like |
|---|---|---|
| Requested interval | How often does the plugin want to run? | 900 seconds |
| Registered interval | What does WordPress have scheduled? | 900 seconds — not missing |
| Next WordPress event | When is the next check due? | Within the next 15 minutes, or slightly overdue |
| Last heartbeat | When did PHP last finish a check? | Within the last 15 minutes |
Plus Last registration result, which reports whether registering the event succeeded.
How Health Is Judged #
The plugin raises attention after two intervals without a heartbeat — 30 minutes at the default setting.
- A newly installed plugin gets a two-interval grace period before anything is flagged.
- A heartbeat is recorded even when no series was due. An idle check is still a successful check.
- Recovery is detected automatically: if a check completes, health returns without you dismissing anything.
The heartbeat is unrelated to WordPress’s browser “Heartbeat API”. Different thing, same word.
Reading the Combinations #
| Registered | Heartbeat | Diagnosis |
|---|---|---|
| 900 | Recent | Healthy. Nothing to do. |
| 900 | Hours old | The event is scheduled but WordPress is not being invoked. Fix cron. |
missing |
Any | The event isn’t registered. Check the registration result and for a DISABLE_WP_CRON setup with no replacement. |
| 900 | None ever | Brand-new install inside its grace period, or WordPress has not been invoked since installation. |
Proving It Yourself #
- Note the Last heartbeat value.
- Wait 15–20 minutes without touching anything.
- Reload the page.
If the heartbeat moved forward, the worker is genuinely running. If it didn’t, no schedule on the site will run on time — fix that first.
What Does Not Prove the Worker Runs #
- A 200 response from
wp-cron.php. That runs due events. If this plugin’s event isn’t due yet, nothing about this plugin happened. - Another plugin’s daily task working. A daily cadence tells you nothing about a 15-minute one.
- A registered event. Registration is a request. The heartbeat is the receipt.
What the Worker Actually Does Each Pass #
| Step | Detail |
|---|---|
| Claims due series | At most 50 per pass, each with an exclusive lock. |
| Submits each one | Recording target, start, finish, outcome and child entry. |
| Respects a time budget | It stops taking new work when the budget runs out; the rest waits for the next pass. |
| Releases locks | Guaranteed cleanup, even on failure. Claims older than 30 minutes are recoverable. |
| Records a heartbeat | Whether or not anything was due. |
Worker Warnings #
When health degrades, the dashboard notice links straight to worker health — not to an empty list of failed submissions, which is the confusing place a worker problem tends to send people.
- The last detected incident and its recovery time stay visible in the health card after the notice clears.
- Opening Queue does not dismiss a worker warning. A completed check can recover health between page loads, and the record explains what happened.
Tuning the Interval (Optional) #
Developers can change the cadence with the rfsfgf_worker_interval filter (900 seconds by default, with a one-minute floor). The health threshold follows it automatically, since “late” is defined as two intervals.
A shorter interval only helps if your host invokes WordPress at least that often. See Developer Reference: Hooks and Filters.
