Alert Exceptions¶
Alert exceptions are per-tenant rules that act on incoming alerts before they reach the Alerts dashboard. Use them to silence repeating false-positives or to downgrade the severity of alerts you want recorded but not paged on.
Open Alerts and click Manage Exceptions in the top-right of the page.
What an exception does¶
Every new alert is checked against the tenant's enabled exceptions in the order they were created. The first exception whose conditions all match the alert decides what happens:
- Suppress — the alert is dropped entirely. Nothing reaches the Alerts list, dashboards, or webhooks. The exception's hit counter still increments so you can confirm the rule is working.
- Override severity — the alert is recorded normally, but its severity is rewritten to the level you pick (low, medium, high, or critical). Useful for keeping a record without the noise.
Each exception has zero or more conditions. All conditions must match (AND semantics) for the rule to fire. Conditions are case-insensitive.
Defining a rule¶
Open the editor by clicking New Alert Exception on the list page, or Edit on an existing row. Fill in:
- Name — a human-readable label. "Suppress DLP hits from the network scanner" is more useful than "rule 4".
- Action — Suppress, or Override severity to low / medium / high / critical.
- Conditions — one or more rows of field + operator + value. Both sides are lower-cased before comparison, so capitalization differences don't matter.
- Enabled — uncheck to keep the rule on file without it firing.
Operators available:
| Operator | What it does |
|---|---|
| Equals | The alert's field value matches the rule's value exactly. |
| Contains | The rule's value appears somewhere inside the alert's field value. |
The field dropdown lists every attribute an alert can be filtered on (user email, site domain, alert type, DLP pattern name, and so on). Values are suggested live from your tenant's existing alerts as you type — point and pick, or free-text anything if you know the value isn't in the suggestion list yet.
Example: silence a known scanner¶
A vulnerability scanner runs nightly against internal-tools.example.com and trips DLP every time. To stop those alerts from reaching the dashboard:
| Field | Operator | Value |
|---|---|---|
| Site domain | Equals | internal-tools.example.com |
| User email | Equals | scanner-svc@firma.ch |
Action: Suppress. Both conditions must match (AND), so genuine user activity on the same host is still alerted on.
Example: downgrade noisy events¶
Dismissed-phishing-warning events from a specific team should be recorded but not page anyone:
| Field | Operator | Value |
|---|---|---|
| Alert type | Equals | Phishing warning dismissed |
| User email | Contains | @sales.firma.ch |
Action: Override severity to low. The alerts still appear on the dashboard with their normal type and details, just at the lower severity.
Hit counter and last-match timestamp¶
Each exception tracks how often it fired and when it last matched an alert. Both columns are visible in the list view.
If you've just tuned a rule and want to confirm it's now silencing the right alerts, click Reset Counter in the row's action menu. The counter zeroes out and Last Match clears; the next match will refill both.
Closing existing alerts when you save¶
When creating or updating a rule, the editor offers a Close all open alerts that match these conditions when saving toggle. With it enabled, on save:
- The rule's conditions are evaluated against currently-open alerts.
- Matching alerts are flipped to closed, with closed/updated timestamps set to the save time. They keep their type, severity, and original creation timestamp.
- The number of closed alerts is shown in the confirmation dialog.
This pairs nicely with first-time tuning: silence future occurrences and clean up the backlog in a single action.
Order and precedence¶
When multiple enabled exceptions could match the same alert, the first one created (lowest ID) wins. Subsequent matching rules are skipped and their counters do not increment.
For a strict "suppression beats override" precedence, create the suppression rules before the override rules — or use distinct conditions so no alert matches more than one rule.
Audit log¶
Creating, updating, and deleting alert exceptions are recorded in the Audit Log with the admin email and source IP. The hit-counter reset is also logged. The hit counter on the rule itself is the operator-visible signal for per-alert match activity.
Scope¶
Exceptions decide which incoming events become recorded alerts.
- Suppressed alerts never reach the dashboard, module dashboards, or webhooks.
- Severity-overridden alerts flow through normally at the rewritten severity, including to webhooks.