Notifications
Every event, from a completed fix to a site going down, shows up in the dashboard's notification bell. Email is reserved for a short, deliberate list of genuinely new and critical problems -- not every routine action you or an automated repair already took.
Every event
In-app
Critical only
By email
Deduplicated
Repeat failures
One click
To the source
How an event becomes a notification
A scan completes, a repair fails, a site goes down, a vulnerability is matched -- any notify-worthy event.
Every event writes to the organization's notification history, visible in the bell, regardless of category.
Only the fixed list of genuinely critical, new-problem categories is ever eligible to also send an email.
A short safety-net window prevents an accidental duplicate call from firing the same notification twice in quick succession.
Every notify-worthy event -- a completed fix, a quarantined file, a repair failure, a connector disconnect -- writes to the notification bell unconditionally, with a read/unread count.
Email only fires for a short, fixed list of events: the site going down, the connector disconnecting, malware detected, a critical vulnerability, a critical health issue, or a trial/billing problem.
A fix completing, a file being quarantined after you clicked Quarantine yourself, a repair failing on a retry -- these are expected outcomes of actions already visible on screen, not surprises worth an email.
Clicking a notification marks it read and, where it's about a specific action, takes you straight to the website or issue it concerns.
Alongside the persistent bell, a genuinely urgent event also shows a short toast that fades on its own -- noticeable in the moment without requiring the bell to already be open.
You'll never get an email just for clicking a button yourself
Site-down, malware, and critical vulnerability events always email
Every event is still visible in-app, regardless of email eligibility
No separate settings screen full of toggles to configure correctly first
Practical guidance
Critical errors
Recover from the WordPress critical error screen with a controlled process that protects evidence, creates a restore point, isolates the cause, and verifies the result.
Read guideAuto repair
Automation should resolve known, reversible WordPress conditions while risky database, malware, and hosting failures remain review-driven.
Read guideBackups
Local restore points make repairs fast, while off-site copies protect against hosting and disk failure. A serious recovery plan needs clear roles for both.
Read guideFAQ
No. A completed repair -- automatic or manual -- shows up in-app only. Email is reserved for the fixed list of critical, new-problem events.
Every attempt still shows up in-app, but repeated failures of the same action don't each trigger a separate email -- avoiding exactly the kind of notification pile-up a retry loop would otherwise cause.
The email-eligible category list is intentionally fixed and conservative rather than user-configurable per event type, so the policy stays predictable across every organization.
The connector shows its own site-specific high-alert banner directly in wp-admin for critical issues on that site, in addition to the SaaS dashboard's notification system.
Free 14-day trial · no card required
Install the connector, pair with a one-time token, and start monitoring in minutes -- upgrade whenever you're ready.