Exporting the Suppression Journal for Audit

4 min read

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).

Exporting the journal

Open the Burrow dashboard → Settings in the left navigation.
Switch to the Suppression journal viewer tab.
Apply filters:
- Reason — single reason, or all reasons.
- Date range — when the suppression happened.
- User — narrow to one entity.
The table paginates the matching entries.
Use your browser's print / save-as functionality on the visible page to capture the output, or take a dated screenshot for an audit binder.

For very large export sets, a support ticket gets you a direct CSV dump for a specified date range.

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.