Table of Contents
Symptom: no series on the site is running. Targets pass and nothing happens.
This is almost always the worker — WordPress isn’t executing the background check.
Step 1 — Read Worker Health #
GravityOps → Recurring Submissions → Queue, top of the screen.
| Reading | Healthy |
|---|---|
| Requested interval | 900 seconds |
| Registered interval | 900 seconds — not missing |
| Next WordPress event | Soon, or slightly overdue |
| Last heartbeat | Within the last 15 minutes |
| Last registration result | No error |
Step 2 — Diagnose by Combination #
| Registered | Heartbeat | Diagnosis | Fix |
|---|---|---|---|
| 900 | Recent | Worker is fine — the problem is elsewhere | Go to A Series Is Not Running |
| 900 | Hours or days old | Event is scheduled, WordPress is not being invoked | Fix cron, below |
missing |
Any | The event isn’t registered | Check the registration result and your cron configuration |
| 900 | Never | New install inside its grace period, or WordPress has not been invoked since installing | Wait one interval, or trigger a visit |
Step 3 — Fix Cron #
Ask your host (or systems team) to invoke WordPress cron every 5 to 15 minutes:
*/10 * * * * cd /path/to/site && php wp-cron.php > /dev/null 2>&1Then wait one interval and reload Queue. If the heartbeat moves forward, it’s fixed.
Things that don’t prove cron is fine #
| Claim | Why it proves nothing |
|---|---|
“wp-cron.php returns 200″ |
It runs due events. If this plugin’s event isn’t due, nothing about this plugin ran. |
| “Our other scheduled task works” | That task may be daily. A daily cron cannot satisfy a 15-minute interval. |
| “The event is registered” | Registration is a request. The heartbeat is the receipt. |
| “The site gets plenty of traffic” | Traffic normally spawns WP-Cron — unless automatic spawning is disabled. |
Step 4 — If the Event Is Missing #
- Read Last registration result in worker health; a scheduling API error is reported there.
- Look for
DISABLE_WP_CRONset with no replacement server cron. - Check for a cron-management plugin that removed or duplicated the event. The plugin repairs stale or duplicate events from earlier versions and records the repair — including the previous timestamp and interval.
Step 5 — Confirm Recovery #
- Note the heartbeat.
- Wait 15–20 minutes.
- Reload.
Moved forward? Fixed. Then watch the Due / overdue card drain over the next few passes.
What Happens to the Missed Occurrences #
Nothing was lost, and nothing will flood in:
- Each series holds one overdue target.
- On recovery, it submits that one occurrence — or skips it, if the feed is set to skip — and continues at its next future time.
- Counts and end dates behave accordingly.
See Missed Runs and Downtime.
If the Worker Is Healthy but Nothing Runs #
Then it isn’t the worker. Check, in order:
| Check | Where |
|---|---|
| Is the feed active? | GravityOps → Feeds tab |
| Are the series paused? | Queue → Paused filter (the default Current view hides them) |
| Do any series exist at all? | Queue with no filters. No rows means no parent entry ever started one. |
| Does the feed’s Enable Condition pass? | The feed’s settings — if it never passes, no entry starts a series |
| Is the form trashed, or the parent missing? | Both prevent submission |
A worker can be perfectly healthy with nothing to do.
Prevention #
- Monitor the heartbeat, not the event.
- Keep a real server cron rather than relying on visitor traffic.
- Set an Admin Email — worker-unhealthy and worker-recovered alerts go there, so you hear about this before your schedules do.
