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. The most important decision here is not which alerts to enable but who actually receives them and whether that person has the access and context to act.
Enter specific email addresses rather than relying on the WordPress admin email. The admin email is often a shared inbox, a billing address, or an account that has not been checked in months.
| 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 during holidays |
| WooCommerce store | Store owner plus the developer or agency responsible for the site. Security issues on a live store affect revenue. |
| Membership or LMS site | Site administrator plus whoever manages member data. Some findings have data protection implications. |
Scan and vulnerability alerts
These are the alerts with the most direct security value. Enable all three.
| Alert | Recommended | Why it matters |
|---|---|---|
| Scan Findings | On | Delivers scan results to someone who can act on them. Without this, findings sit in the SiteFort dashboard until someone manually checks it. |
| New Vulnerability Found | On | Triggers when a newly disclosed CVE matches something installed on the site. This is time-sensitive. A new Critical vulnerability can be actively exploited within hours of disclosure. |
| Scan Failed | On | A failed scan means the site went unmonitored for that period. Without this alert, a recurring scan failure can go unnoticed for weeks. |
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 reduce noise, with a separate review process for Medium findings during maintenance |
| High-risk or compliance-sensitive site | All severities |
Firewall and login alerts
| Alert | Recommended | Watch out for |
|---|---|---|
| Firewall Block Summary | On | Use a Daily digest for active sites, Weekly for low-traffic sites. Real-time firewall alerts generate too much noise on most sites. The summary format is enough to spot trends and spikes. |
| Login Lockout | On | Helps distinguish real user lockouts from bot activity. If lockout alerts arrive constantly from the same IP range, that is a signal to add a firewall rule, not to disable the alert. |
Account activity alerts
These alerts cover changes that attackers make after gaining access. They are not high-volume and should always be enabled. An attacker who reaches the WordPress admin will often try to disable security tools, create a new admin account, or change 2FA settings before taking further action.
| Alert | Recommended |
|---|---|
| SiteFort Deactivated | On |
| Sensitive Tool Used | On |
| Two-Factor Authentication Change | On |
| Administrator Sign-In | On |
If you receive a SiteFort Deactivated or 2FA Change alert and did not trigger it yourself, treat it as an active incident. Check the Audit Log immediately for the triggering user, IP, and timestamp.
Webhook delivery
Go to SiteFort → Settings → Notifications → Webhook Delivery.
Use webhooks if alerts need to reach a team channel, a ticketing system, or an operations workflow rather than individual email inboxes. Webhooks work alongside email, not instead of it.
| 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 setting up a custom endpoint. |
After saving a webhook URL, use Send test to confirm delivery before relying on it. A misconfigured webhook that silently fails is worse than no webhook at all, because it creates false confidence that alerts are being received.
Simple weekly security review
Notifications catch urgent issues in real time. A short weekly review catches everything else before it becomes 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.