Start here. Four checks, in order, narrow almost any problem to one page of this section.
The Four Checks #
1. Is the worker healthy? #
GravityOps → Recurring Submissions → Queue, top of the screen.
If the heartbeat is stale, stop here. Nothing else will run correctly and every other symptom is downstream of it.
→ Nothing Is Being Submitted
2. Is the series in a state that runs? #
Look at the Status column.
| Status | Runs automatically? |
|---|---|
| scheduled | Yes |
| processing | In progress |
| paused | No |
| failed | No |
| completed / canceled | No |
Also check the badge next to it: a series can be scheduled but sitting behind an inactive feed.
3. Is the target what you expect? #
Compare the Next run and window column with what you intended.
- Wrong target → the problem is the series’ schedule. Editing the feed alone never changes an existing snapshot.
- Right target, late attempt → the problem is timing. Get the evidence before guessing.
4. What does the attempt history say? #
View attempt history gives you the target, the actual start and finish, the source, the outcome, the lateness, the timing explanation and any validation field IDs.
Nearly every question is answered in that panel.
Symptom → Page #
| Symptom | Go to |
|---|---|
| Nothing runs anywhere on the site | Nothing Is Being Submitted |
| One series doesn’t run, others do | A Series Is Not Running |
| Submissions happen, but late | Submissions Run Late |
| A submission failed | A Submission Failed |
| Values in the child entry are wrong or empty | Values Are Wrong or Empty |
| A series says it is locked or blocked | A Series Is Locked or Blocked |
| You need to send evidence to support | Logging and Copy Diagnostics |
Three Things That Are Not Bugs #
A few minutes of lateness #
A healthy worker starts an occurrence between its target and roughly 15 minutes afterwards. That’s the design.
Feed edits not affecting running schedules #
Each series carries its own schedule snapshot. This is deliberate — see How Scheduling Works.
One submission after a long outage #
A series holds one target, never a queue. One overdue occurrence runs (or none, if the feed skips). Nothing replays.
Evidence Before Theories #
The order that actually resolves things:
- Queue — state, target, last attempt.
- Attempt history — what happened and when.
- Worker health — did the check run at all?
- The add-on log — enable it at Forms → Settings → Logging if you need per-step detail.
- Copy Diagnostics — when it’s time to involve support.
A requested interval is not proof that PHP executed the worker. A registered event is not proof either. The heartbeat is the proof.
Before You Contact Support #
Have ready:
- The attempt log ID from history.
- The Copy Diagnostics report — already redacted, safe to send as it stands.
- The add-on log excerpt, if logging was enabled.
- What you expected, and what happened instead.
Don’t send entry exports, screenshots of submitted values or credentials. The diagnostics report deliberately omits all of those, and it’s enough.
