Security Notifications
Security alerts turn SiteFort from a one-time setup into active monitoring. Which alerts to enable, who should receive them, and how to route them so they actually get acted on.
Who gets alerts
Go to SiteFort → Settings → Notifications.
An alert nobody reads is the same as no alert. That's the whole game on this page. Which alerts you flip on matters far less than who actually receives them, and whether that person has both the access and the context to do something the moment it lands.
Use specific email addresses rather than defaulting to the WordPress admin email. That address is, more often than not, a shared inbox, a billing contact, or an account nobody's opened in months, which makes it a poor place to send anything time-sensitive.
| Site type | Recommended recipient |
|---|---|
| Owner-operated small business | Site owner directly, or a developer who has an ongoing relationship with the site |
| Agency-managed client site | Agency support inbox or a dedicated security mailbox, not a personal developer email that goes quiet the moment someone's on vacation |
| WooCommerce store | Store owner plus the developer or agency responsible for the site. A security issue on a live store is a revenue issue by the time anyone notices it. |
| Membership or LMS site | Site administrator plus whoever manages member data. Some findings here carry real data protection implications, not just technical ones. |
Scan and vulnerability alerts
Of everything on this page, these three carry the most direct security weight. Turn all three on, there's no version of "maybe just two of these" that makes sense.
| Alert | Recommended | Why it matters |
|---|---|---|
| Scan Findings | On | Gets results in front of someone who can act, instead of sitting in the dashboard waiting for someone to think to check it. |
| New Vulnerability Found | On | Fires the moment a newly disclosed CVE matches something installed on the site. This one is genuinely time-sensitive, a fresh Critical vulnerability can be under active exploitation within hours of being disclosed publicly. |
| Scan Failed | On | A failed scan means the site went unwatched for that stretch of time. Without this, a scan that's been silently failing for weeks looks identical to a site with nothing to report. |
Severity threshold
| Situation | Recommended threshold |
|---|---|
| Single site, owner or developer receiving alerts | Medium and above |
| Agency inbox receiving alerts from many client sites | High and above to keep the inbox usable, with a separate, deliberate review pass for Medium findings during maintenance windows |
| High-risk or compliance-sensitive site | All severities |
Firewall and login alerts
| Alert | Recommended | Watch out for |
|---|---|---|
| Firewall Block Summary | On | Daily digest for active sites, Weekly for quieter ones. Real-time alerts for every single firewall block will bury you in noise on most sites, a digest is plenty to spot the trends and spikes that actually matter. |
| Login Lockout | On | Helps separate a real user locked out of their own account from bot traffic getting rejected as designed. If the same IP range keeps generating lockout alerts, that's telling you to add a firewall rule, not to mute the alert. |
Account activity alerts
These cover the moves an attacker makes right after they've already gotten in, which is exactly why they matter so much. Someone who's reached the WordPress admin area will often move fast: disable your security tools, create a new admin account, or mess with 2FA settings before doing anything more visible. These alerts are low-volume by nature, so there's no real cost to leaving all of them on.
| Alert | Recommended |
|---|---|
| SiteFort Deactivated | On |
| Sensitive Tool Used | On |
| Two-Factor Authentication Change | On |
| Administrator Sign-In | On |
If a SiteFort Deactivated or 2FA Change alert shows up and you know you didn't trigger it, don't shrug it off, treat it as an incident happening right now. Go straight to the Audit Log for the triggering user, IP, and timestamp before doing anything else.
Webhook delivery
Go to SiteFort → Settings → Notifications → Webhook Delivery.
Reach for webhooks when alerts need to land in a team channel, a ticketing system, or an existing operations workflow rather than an individual's inbox. Set them up alongside email, not as a replacement for it, since the two catch different failure modes for getting someone's attention.
| Use case | Recommended provider |
|---|---|
| Agency team monitoring multiple client sites | Slack or Discord channel dedicated to security alerts |
| Operations team with an existing ticketing or alerting workflow | Generic JSON webhook to the relevant endpoint |
| Solo developer or small team who already uses Slack | Slack. Lower barrier than standing up a custom endpoint just for this. |
Once you've saved a webhook URL, click Send test before you trust it with anything real. A webhook that's silently failing is worse than having no webhook at all, since it hands you false confidence that alerts are actually going somewhere when they aren't.
Simple weekly security review
Notifications are built to catch the urgent stuff the moment it happens. A short weekly pass is what catches everything else before it has the chance to become urgent:
- Check scan findings and resolve anything new.
- Review Vulnerability Scanner results and update any newly flagged components.
- Scan the Traffic Log for unusual patterns or sustained abuse from a specific source.
- Check login lockouts and confirm no legitimate users are being repeatedly blocked.
- Review new administrator accounts if any were created since the last review.
- Remove firewall allow rules that are no longer needed. It's easy to add these under pressure and forget they're still there months later.