Exporting the Suppression Journal for Audit

4 min read · Last updated 3 August 2026 · Page version 4

For an external audit or compliance review, you may need to prove what Burrow chose not to email and why. The suppression journal is the audit trail of every alert Burrow suppressed - by operator dismissal, entity exception, AI verdict, cooldown, or any other layer in the email pipeline.

This article walks the export workflow and explains how to use the reasons to answer specific compliance questions.

What the suppression journal records

Every time Burrow's email step decides not to send a per-alert email, it writes one entry to the suppression journal with:

Timestamp - when the suppression happened.
User and category - which (user, alert category) pair was suppressed.
Severity - the severity Burrow assigned before the suppression.
Reason - why the alert was skipped (see the reasons table below).

This means the journal is the answer to "did Burrow alert us about X?" and "why didn't we get an email about Y?"

Reasons you will see

Reason	What it means
`entity_exception`	The user matched an operator-defined entity exception with action=Suppress.
`entity_exception_incident`	An incident card was suppressed because all its constituent alerts matched an entity exception.
`below_min_severity`	The alert's severity was lower than the recipient list's Minimum severity gate.
`cooldown`	The same (user, category) pair already emailed within the cooldown window (one hour).
`llm_dismissed`	The AI triage step verdict was "not real".
`auto_downgrade`	An entity exception with action=Downgrade reduced the alert's severity below the minimum gate.
`dedup_incident`	A consolidated incident card has already been sent that covers this alert.
`daily_escalation_dedup`	A daily-pattern escalation summary has already been sent for this user today.
`daily_escalation_cap`	The daily escalation queue hit its per-cycle send cap; the alert will be re-considered next cycle.
`rule_filter_exclude_hit`	The category was on the operator's exclude list (Rules mode = Selected).

Seeing suppressions in the dashboard

For day-to-day questions - "why wasn't I emailed about that?" - use the System Activity page:

Open the Burrow dashboard → System Activity in the left navigation.
Use the Suppressed filter chip to show only alerts that were not emailed, each with its reason.
Search by entity to narrow to one person, and page through with the position indicator.

The feed covers the last 48 hours. Suppressed alerts also remain in the Alerts history, flagged as not-real, so the forensic record is preserved beyond that window.

Getting a full extract for an audit

For a complete, per-decision record over a longer date range - the kind of thing that goes in an audit binder - raise a support ticket and ask for a suppression-journal extract for the period you need. The underlying journal is held on the Burrow server rather than exported from the dashboard, so this is the supported route for bulk audit evidence.

For a lighter-weight record you can produce yourself, use your browser's print / save-as on a filtered System Activity view, or take a dated screenshot.

Common audit questions and the queries that answer them

"Did Burrow ever suppress an alert via the AI verdict alone, without a human reviewing it?"

Filter Reason to llm_dismissed. The result set is every alert the AI marked "not real" and Burrow then skipped emailing. Each entry includes the (user, category) pair so you can spot any pattern an auditor would consider material.

"Show me every alert we suppressed for service account X in the last quarter."

Filter User to the service account's UPN pattern and date range to the quarter. Most entries will read entity_exception (the intentional silence rule); any other reason is worth investigating.

"How many critical-severity alerts did we suppress in the last 90 days?"

Filter date range to the 90-day window. Sort or filter by severity in the export to show critical-only.

Why this matters

The suppression journal turns a "trust us" answer into a "here is the evidence" answer. Compliance reviewers, internal audit, and regulators want to see that:

Every alert that did not reach the SOC was suppressed for a documented reason.
The reasons are auditable and the journal is append-only.
Operator-driven suppressions (entity exceptions, manual dispositions) are tied to a named operator via the admin audit log.