Three separate systems tell you what’s happening. They’re easy to confuse, so here they are side by side.
| System | Who it’s for | Where it’s configured |
|---|---|---|
| Gravity Forms notifications | Anyone — recipients, staff, the submitter | Forms → (form) → Settings → Notifications |
| Operational alerts | The site administrator | GravityOps → Recurring Submissions → Settings (Admin Email) |
| The dashboard notice | Administrators using WP admin | Not configurable; dismissed per user |
1. Gravity Forms Notification Events #
The plugin registers three events you can attach an ordinary Gravity Forms notification to.
| Event | Fires when |
|---|---|
| Successful Resubmission | A child entry was created. |
| Failed Resubmission | The first failure in a new active issue. |
| Resubmissions Completed | The series reaches completion. |
Choose one in the notification’s Event dropdown, then write it like any other Gravity Forms notification — including conditional logic and merge tags.
Note: a Failed Resubmission notification fires on the first failure of a sequence, not on every consecutive failure. That keeps a broken form from mailing you three times before it stops itself.
Because children are created through normal Gravity Forms processing, your existing notifications fire on child entries too. If you don’t want that, add conditional logic using {is_auto_submission} — see Merge Tags and Entry Meta.
2. Operational Alerts to the Admin Email #
The Admin Email in global settings receives alerts on operational transitions:
| Transition | Meaning |
|---|---|
| First failure | A series just developed a problem. |
| Failure threshold reached | A series stopped its automatic attempts. |
| Recovery | A previously failing series submitted successfully. |
| Worker unhealthy | The background check has not completed in time. |
| Worker recovered | It is running again. |
Each message names the series and links to Queue → Needs attention.
What these alerts are not: a periodic digest of the full failure log. A maintenance scan that finds nothing new sends nothing. Historical failures are never re-sent.
3. The Dashboard Notice #
One short paragraph at the top of the WordPress admin, with the affected-series count and a link to Queue → Needs attention. The details live in Queue, not in the notice.
| Property | Behaviour |
|---|---|
| Size | Stays compact no matter how large the history is. |
| Dismissal | Per administrator, stored against the displayed issue revision. |
| Persistence | Stays dismissed while the issue is unchanged. A new failure sequence or an escalation increments the revision and brings it back. |
| Warning severity | Retries are still scheduled. |
| Error severity | Series have stopped, or the worker is unhealthy. |
A worker warning links directly to worker health rather than to a list of failed submissions — because with an unhealthy worker that list is usually empty, which is the most confusing possible destination.
Current Issues and Bounded Retries #
An “issue” is the plugin’s record that a series is currently in trouble.
How an issue opens and closes #
- Opens on the first failure in a sequence.
- Escalates as consecutive failures accumulate.
- Stops the series at the threshold — 3 by default, configurable globally or per feed.
- Closes on a successful submission, which also resets the consecutive count.
What never counts as a failure #
- A conditional skip, on either the child or parent check.
- A skipped missed run.
- Lateness alone. A late-but-successful attempt is a success.
None of these raise the successful-submission count either.
Reopening automatic attempts #
After you’ve corrected the cause, Resume or a schedule edit lets automatic attempts run again. The issue stays visible until a submission actually succeeds — the plugin never marks a problem solved on your say-so.
The Maintenance Scan #
A separate periodic scan runs twice a day by default and:
- checks worker health,
- recovers stale claims,
- prunes expired operational history.
It never submits a form, and it never re-sends your failure log.
Developers can retune it with rfsfgf_failed_check_interval and rfsfgf_failed_check_first_run.
Sending Alerts Somewhere Else #
Prefer Slack, a helpdesk or a log? Use the transition hooks instead of the email:
| Hook | Fires on |
|---|---|
rfsfgf_series_first_failure |
The first failure in a sequence. |
rfsfgf_series_failed |
The failure threshold being reached. |
rfsfgf_series_recovered |
Recovery after a success. |
rfsfgf_attempt_started / rfsfgf_attempt_completed |
Structured per-attempt events. |
See Developer Reference: Hooks and Filters. Do not log field values or full entry data in an extension — the plugin’s own records are redacted deliberately.
