Audit alerts
This page is for security officers and administrators who must be told when something risky happens on a public
website. The audit trail evaluates alert rules on its records and sends alerts to syslog, mail or a webhook. Sources:
settings/audit.ini and the audit guide, section 4.5.
Contents
- The shipped rules
- Who receives them
- Where to see them
- Tuning and testing
- Routing to your security team
- Related pages
The shipped rules
| Rule | Fires when | Severity | Sinks |
|---|---|---|---|
brute_force | 20 failed sign-ins from one network within 300 seconds | critical | syslog, mail |
brute_force_user | 10 failed sign-ins for one account within 900 seconds | alert | syslog, mail |
admin_role_granted | a role with */*, setup/*, role/* or audit/manage is assigned | critical | syslog, mail |
settings_out_of_hours | a setting is written outside business days 1-5, hours 7-19 (site time zone) | warning | syslog |
mass_delete | 500 nodes removed by one user within 600 seconds (children counted) | critical | syslog, mail |
audit_disabled | the audit is switched off | emergency | syslog |
chain_broken | verification finds a broken chain | alert | syslog, mail |
Alerts are evaluated when records are flushed and in the audit cronjob part (frequent part); make sure that part
runs (Cronjob monitoring).
Who receives them
Mail goes to the rule's Recipients[], else [AuditAlertSettings] Recipients[], else [AuditSink_mail] Receivers[],
else the site's AdminEmail. Recipients can be addresses, named groups (group:security), users, user groups or a
role (role:Administrator). At most one mail per rule and recipient within 900 seconds. Check:
./console exp:audit alerts recipients --allow-root-user
./console exp:audit alerts list --allow-root-userUse a function mailbox (for example the security team's shared address), not one person's address, so alerts survive leave and staff changes.
Where to see them
- Audit tab, Alerts (
/audit/alerts): fired alerts and the rules with kind, event, threshold, sinks and state. - The audit dashboard's Alerts panel.
- Syslog: with
Transport=localthe records reach journald,journalctl -t exponential.
Tuning and testing
Replay a rule against a past day before changing it:
./console exp:audit alerts test mass_delete --replay=2026-09-01 --allow-root-userOverride thresholds, business hours (BusinessDays, BusinessHours) or recipients in
settings/override/audit.ini.append.php, through your change process. Typical public-sector adjustments: business
hours matching your service hours; the security team as recipient of admin_role_granted and brute_force;
settings_out_of_hours also by mail if settings should never change outside a window.
Routing to your security team
If your organization runs a security operations center or a SIEM, feed it from the syslog sink or the signed webhook sink (HMAC-SHA-256 over timestamp and body, spooled with retries) rather than from mail (Audit trail, "Sinks, alerts and archives"). Agree what each alert means for them and who calls whom; the incident pages give the first steps.
Related pages
- Audit trail verification
- Check who gets audit alerts
- Suspected account compromise
- Audit trail (hosting)
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.