---
title: Notifications and Alerts
description: "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**…"
url: "https://brightleafdigital.io/docs/notifications-and-alerts/"
updated: "2026-10-18"
category: Recurring Form Submissions for Gravity Forms / Settings Reference
---

# Notifications and Alerts

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

1. **Opens** on the first failure in a sequence.
2. **Escalates** as consecutive failures accumulate.
3. **Stops the series** at the threshold — 3 by default, configurable globally or per feed.
4. **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.