Three settings apply site-wide, to every feed and every series. They live at GravityOps → Recurring Submissions → Settings.
The Settings #
| Setting | Default | Range | What it controls |
|---|---|---|---|
| Admin Email | Site admin email | Any email address | Where operational alerts are sent — first failure, threshold reached, recovery, worker unhealthy, worker recovered. |
| Default consecutive failure limit | 3 |
1–100 | How many consecutive failures stop a series’ automatic attempts. Any feed can override it. |
| Operational history retention (days) | 90 |
1–3650 | How long attempt records, and completed/canceled series, stay queryable. |
Click Save Settings to apply. The screen confirms with a notice.
Admin Email #
Leave it blank to use the site’s own admin email.
What arrives here:
- The first failure in a new sequence.
- A series reaching the failure threshold and stopping.
- A series recovering after a successful submission.
- The worker becoming unhealthy, and the worker recovering.
What does not arrive here: a periodic digest of your whole failure history. Alerts are tied to operational transitions — a scan that finds nothing new sends nothing.
Want the alerts somewhere else, or formatted differently? Use the transition hooks in Developer Reference: Hooks and Filters.
Default Consecutive Failure Limit #
A series counts consecutive failures. When the count reaches the limit, automatic attempts stop and the series enters the failed state.
- A success resets the count to zero and resolves the issue.
- Skips never count — neither conditional skips nor skipped missed runs.
- A feed can override this globally-set number in its own Consecutive failure limit field; blank there means “inherit this value”.
Choosing a number:
| Limit | Suits |
|---|---|
1 |
Schedules where a failure must be looked at immediately. |
3 (default) |
Most sites — tolerates a transient glitch, stops a genuinely broken form. |
10+ |
Schedules that depend on an external service with occasional outages. |
Operational History Retention #
Retention governs the plugin’s own operational records:
Kept for the retention window:
- Attempt records — targets, timings, outcomes, child entry IDs, timing explanations.
- Completed and canceled series rows.
Never removed by retention:
- Child entries.
- Entry notes.
- Anything Gravity Forms owns.
Expired records are pruned in bounded batches by the maintenance scan, so a long history never produces one enormous delete.
Because completed and canceled series are retained, the
[rfsfgf_overview]shortcode’sallstatus lists more than it used to. Ask for the status you want explicitly.
What Else Is on This Screen #
Below the settings card:
- Worker health — requested interval, registered interval, next WordPress event, last heartbeat, last registration result, and the last recorded incident. See Checking the Worker Before You Rely On It.
- A link to Queue, where per-series operations happen.
What Is Not Configured Here #
A common wrong turn: these are global settings only. Anything about a specific schedule lives elsewhere.
| To change… | Go to |
|---|---|
| How often a schedule repeats | The feed — Forms → (form) → Settings → Recurring Submissions |
| When one series next runs | Change next submission, in Queue or on the entry page |
| Whether a feed runs at all | The Feeds tab, or the feed’s own activation toggle |
| The schedule of series that already exist | Apply the saved feed schedule, with preview and confirmation |
Permissions #
Saving these settings requires the Gravity Forms settings capability, evaluated through the add-on framework — so administrators whose access comes via full-access capability can save them.
Operational actions require recurring_form_submissions_manage_resubmissions, which is a separate capability.
