In-app notifications: a bell that knows which site and which form

Failures, recoveries, outages, SSL expiries, deliverability problems, lead-volume anomalies and checkout issues surface in the dashboard, tagged by site and form, color-coded by severity.


May 19, 2026 · Formitor

Email alerts work until the inbox eats them. Slack alerts work until the channel scrolls. If you live in the Formitor dashboard anyway, the alerts should live there too.

What shipped

A bell in the dashboard’s top bar now surfaces everything the alert pipeline produces:

  • Form failures and recoveries
  • Site outages
  • SSL expiries
  • Deliverability problems
  • Lead-volume anomalies
  • Checkout issues

Each notification is tagged with the site (and form) it’s about and color-coded by severity, so a glance separates “a form on one site needs attention” from “a client’s store checkout is down”. Mark them read, dismiss them, or click straight through to the thing that fired.

Alongside, not instead

These arrive in addition to your existing email, Slack, Teams and SMS alerts, not as a replacement. The routing philosophy stays the same: alerts fire only on a confirmed change of state, after the re-check buffer agrees the failure is real. The bell doesn’t get noisier than your other channels; it’s the same signal, one more place you can’t miss it.

The small design decision that matters

Every notification names its site and form. That sounds obvious, but generic “something failed, log in to see what” alerts are the fastest way to train yourself to ignore monitoring. When the notification itself says quote form on pinewood-roofing.com, you can triage from the bell without a single click, and the alerts you do click are the ones that deserve it.

Catch the failure before the client does.

Free plan: 2 sites, every feature, no card. See what it finds.