- First, the Rule That Governs This Whole Screen
- Identification and Eligibility
- Schedule Fields
- Preview Before You Save
- How the First Occurrence Is Chosen
- Calendar and Daylight Saving
- Missed Runs
- Input and Submission Options
- Conditional Logic on Every Run
- Changing Existing Schedules Deliberately
- Execution Window
Every setting on Forms → (your form) → Settings → Recurring Submissions, grouped the way the screen is.
First, the Rule That Governs This Whole Screen #
A feed defines defaults for new series. Saving it never rewrites series that already exist.
Each series receives its own normalized schedule snapshot when it starts, and keeps it until you explicitly edit that series or explicitly apply the saved feed defaults to it.
If you take one thing from this page, take that.
Identification and Eligibility #
| Field | What it does |
|---|---|
| Feed Name | Identifies the feed in Queue, the Feeds tab and entry notes. Make it descriptive. |
| Feed Label | An optional label shown on entry cards. Supports merge tags, so it can be entry-specific. |
| Enable Condition | Gravity Forms conditional logic deciding whether a submitted entry starts a series at all. |
Schedule Fields #
| Field | Meaning |
|---|---|
| Repeat every | A whole number from 1 to 1000. |
| Calendar unit | Days, Weeks, Months or Years. |
| Run time | Preserve original submission local time, or Specified local time. Feeds saved before this setting existed preserve the parent’s time. |
| Specified time (HH:MM) | 24-hour clock: 01:20 is 1:20 AM, 13:20 is 1:20 PM. Shown only in specified-time mode. |
| Timezone | Defaults to the WordPress timezone. Use an IANA name such as America/New_York so DST is handled. |
| Monday–Sunday | Allowed weekdays. At least one must stay checked. A slot landing on a disallowed day moves forward to the next allowed one. |
| Missed runs | What happens to an occurrence the worker was not running for. See below. |
| End condition | Number of successful submissions, an end date, or a count from a Number field on the parent. |
| Successful submission limit | The additional successful submissions a count-based schedule requires. The parent is not counted. |
| End date and local time | An inclusive upper bound in the schedule timezone, using Gravity Forms’ date/time controls. |
| Parent Number field | Number fields on this form, labelled with their field IDs. Shown only for the parent-field end condition. |
| Consecutive failure limit | Blank inherits the global default of 3. Otherwise 1–100. |
Only the inputs relevant to your current selections are shown, and only active settings are validated. Switching between modes preserves what you typed in the other one.
Preview Before You Save #
Preview next five occurrences shows exact local dates, times and timezone for a parent submitted right now.
- A count or end date may produce fewer than five.
- Preserve original submission local time uses the real parent’s timestamp once a series actually starts.
- In parent-field mode the feed preview shows cadence without a submission count, because no parent exists yet. Queue previews use the real parent’s count.
How the First Occurrence Is Chosen #
A new schedule applies the recurrence interval first, and then the clock time.
A daily parent submitted September 14 at 01:14 with a specified time of 01:20 starts on September 15 at 01:20 — not six minutes later.
To get an earlier first run, use Change next submission on the series. Saving feed settings alone never moves an existing target.
Calendar and Daylight Saving #
| Situation | Behaviour |
|---|---|
| Normal day | An 11:00 schedule stays at 11:00 across DST changes. |
| Spring-forward gap | A time that doesn’t exist moves to the first valid instant after the gap. |
| Autumn overlap | The first of the two occurrences is used. |
| Month-end / leap day | An unavailable anchor day clamps to the last day of that period, and returns to the anchor day whenever it exists again. |
| Fixed UTC offset | Cannot follow DST. The editor links to your WordPress timezone settings when the site uses one. |
Missed Runs #
A series holds one next target, never a queue — so an outage never accumulates pending occurrences. This setting decides what happens to that single overdue target when the worker comes back.
Run one missed occurrence, then continue (default) #
- The overdue occurrence is submitted once, then the series continues at its next future time.
- A daily 11:00 series whose worker stopped for five days creates one child entry on recovery, not five. Its successful count rises by one.
- This is exactly what every feed saved before this setting existed already did.
Skip missed occurrences and continue at the next future time #
- Nothing is submitted for the outage.
- The occurrence is still recorded in attempt history with its target, actual time and lateness, so the gap stays auditable.
- Successful and consecutive-failure counts are unchanged — exactly like a conditional skip. A skipped run neither consumes a count limit nor counts toward the failure threshold.
What counts as “missed” #
Ordinary lateness is not a missed run. A healthy worker polls, so occurrences normally start somewhat after their target.
An occurrence is treated as missed only once it is more than twice the worker interval late — 30 minutes at the default 15-minute setting, the same threshold worker health uses.
Developers can change that window with rfsfgf_missed_run_grace; it can never go below one worker interval.
Scope #
- Skipping applies to automatic execution only. Run Next Submission Now and Retry Failed Submission always submit, however late the target is.
- Changing this setting affects new series. Apply the saved schedule to existing series to change theirs.
- A series that skips missed runs says so in its schedule summary, both in Queue and on the entry page.
Input and Submission Options #
Input mode #
Input mode: Snapshot (unchecked = Dynamic)
| Mode | Behaviour |
|---|---|
| Snapshot | Captures saved parent values when the series starts, including compound inputs. Later parent edits don’t change it, and Populate Anything values are never re-evaluated. |
| Dynamic | Reloads the current saved parent, seeds Populate Anything dependencies from those values, and evaluates populated fields in dependency order. Empty results replace old values, so blank-result notifications can fire. |
A Dynamic form that depends on Populate Anything reports a specific issue when the dependency is unavailable. Forms without Populate Anything simply continue.
Full comparison: Choosing Snapshot or Dynamic Inputs.
Update Date Field(s) #
Select the date fields that should be set to the current date on each submission, in the schedule’s timezone. The list shows the date fields on this form; if the form has none, the setting doesn’t appear.
Fields the plugin never freezes #
- Calculation and unique-ID fields are generated by their Gravity Forms integrations on each child.
- A Number field supplying the recurrence count is set to zero on children.
Conditional Logic on Every Run #
Two optional checks appear only while feed conditional logic is enabled:
| Setting | Evaluated against |
|---|---|
| Conditional Logic (Child Entry) | The final hydrated submission that is about to be created, including any date updates. |
| Conditional Logic (Current Parent Entry) | The parent entry as currently saved in the database. |
If either check fails, that occurrence is skipped and the schedule continues.
A conditional skip:
- creates no child entry,
- does not raise the successful count,
- does not count as a failure,
exactly like a skipped missed run.
Changing Existing Schedules Deliberately #
When series already exist, the feed editor offers an unchecked action: “Apply the updated schedule to N existing series.”
The flow #
- Check the box and save — or, after saving, follow “Preview and apply saved schedule to existing series.”
- Queue opens a separate preview. Nothing propagates until you confirm.
- Enter specific series IDs, or leave the selection blank for all non-completed series on that feed.
- Review the affected count, representative current and proposed schedule summaries, and proposed targets.
- Confirm.
What application does #
| Copied | Preserved | Never done |
|---|---|---|
| Schedule settings | Progress and successful counts | Backfilling missed occurrences |
| A new series revision | Attempt history | Resuming a paused series |
| A recalculated future target | Input mode and other execution choices | Touching locked or concurrently changed series (they’re skipped and reported) |
Application runs in bounded batches, so a feed with hundreds of series does not time out.
For a single series #
Use Change next submission in Queue or on its entry page. Enter the full next date and time, preview, then save.
- The existing recurrence interval continues from the date and time you chose.
- Progress and limits are preserved.
- It does not resume a paused series.
- To change the recurrence interval, edit the feed and then explicitly apply the saved schedule.
Execution Window #
The requested worker interval is 15 minutes by default. With a healthy worker, an occurrence starts between its target and roughly 15 minutes afterwards, subject to request duration.
WP-Cron has to actually be invoked that often. Queue reports requested interval, registered event and observed heartbeat separately so you can tell the difference between “scheduled” and “ran”.
