Symptom: other schedules work, but this one doesn’t. The worker is healthy.
Work down this list — the causes are in rough order of how often they turn out to be the answer.
1. Is It in Queue at All? #
Clear the filters and search for the form or feed.
No row? Then no series was ever created. Causes:
| Cause | Check |
|---|---|
| The feed’s Enable Condition didn’t pass for that entry | Compare the entry’s values with the condition |
| The feed was inactive when the entry was submitted | Feeds tab |
| The entry was created before the feed existed | Use Start Series From Now on the entry |
| The series was canceled when the parent was trashed | Restore the parent, then Start Series From Now |
Remember Queue’s default Current filter hides paused, completed and canceled series. Switch to All before concluding a series doesn’t exist.
2. What Is Its Status? #
| Status | Why it isn’t running | Fix |
|---|---|---|
| paused | Paused by a person, or by feed deactivation | Resume — or reactivate the feed for feed_inactive series |
| failed | Hit the consecutive-failure threshold | Fix the cause, then Retry or Resume |
| completed | Limit reached, or its parent/feed is gone | Start Series From Now for a new series |
| canceled | Ended deliberately, or its parent was trashed | Start Series From Now |
| processing | Currently claimed | Wait — claims older than 30 minutes are recoverable |
3. Is the Feed Active? #
The status badge says feed active or feed inactive.
An inactive feed pauses its scheduled series and blocks a claimed series at the final guard before submitting.
Fix: reactivate the feed on the Feeds tab. That resumes only the series paused by the feed toggle — user-paused and failed series still need their own Resume.
4. Is the Next Target in the Future? #
Check Next run and window.
If the target is days away, the series is working correctly and you’re simply looking at it between runs.
If the target is wrong:
- The feed was edited after the series started — feed edits don’t rewrite existing snapshots.
- Someone used Change next submission.
- Allowed weekdays pushed the slot forward to the next permitted day.
Fix: use Change next submission for this one series, or apply the saved feed schedule to a set of them.
5. Is It Skipping Rather Than Failing? #
Open View attempt history. A skip looks like an attempt with no child entry, no failure and no change to the counters.
| Skip type | Cause |
|---|---|
| Conditional skip | The child or parent conditional check didn’t pass |
| Skipped missed run | The occurrence was more than twice the worker interval late and the feed is set to skip |
Neither is an error. A series can skip forever and never trip the failure threshold.
Fix: adjust the conditional logic, or change the missed-run policy — see Skip Runs with Conditional Logic and Missed Runs and Downtime.
6. Is It Blocked Pending Review? #
If the row says submission records need review, a storage failure may have created a child entry before its records were saved.
Submissions are blocked deliberately so a retry can’t duplicate a real entry.
Fix: inspect the named child entry and the attempt history, confirm what actually happened, then proceed. Cancel remains available and never deletes children.
7. Has It Quietly Completed? #
Check Progress.
12 / 12 means the limit was reached. An end-date schedule past its date is finished too — end dates are inclusive but final.
Fix: raise the limit on the feed and apply the saved schedule, or start a new series.
A Fast Way to Test #
Click Run Next Submission Now.
| Result | Meaning |
|---|---|
| A child entry is created | Configuration is fine — the issue is scheduling or the worker |
| It fails with field IDs | A form or data problem — see A Submission Failed |
| It reports locked | Something is processing it; wait |
| The button isn’t there | The state or the feed prevents it — see the tables above |
Manual runs always submit, however late the target — so this cleanly separates “can’t submit” from “isn’t being asked to submit”.
