---
title: Nothing Is Being Submitted
description: "**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**,…"
url: "https://brightleafdigital.io/docs/nothing-is-being-submitted/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Troubleshooting Recurring Form Submissions For Gravity Forms
---

# Nothing Is Being Submitted

**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>&1
```

Then 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

1. Read **Last registration result** in worker health; a scheduling API error is reported there.
2. Look for `DISABLE_WP_CRON` set with no replacement server cron.
3. 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

1. Note the heartbeat.
2. Wait 15–20 minutes.
3. 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.