---
title: Checking the Worker Before You Rely On It
description: "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:…"
url: "https://brightleafdigital.io/docs/checking-the-worker-before-you-rely-on-it/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Setup
---

# Checking the Worker Before You Rely On It

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

1. Note the **Last heartbeat** value.
2. Wait 15–20 minutes without touching anything.
3. 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*.