Email Types Burrow Sends

Burrow sends four kinds of email. Knowing which kind you have received - and which kind suppresses which other kind - is the difference between reading the email correctly and getting confused about "why did I get THIS specific email?". This page is the reference.

The four types

1. Per-alert email

When sent: any individual rule fires AND the alert's severity is at or above your Minimum severity gate AND none of the suppression layers (described below) skipped it.

Held briefly for the AI verdict (2026-07-22; incident cards too, 2026-07-27). A new alert is now held for a few minutes before the email goes out, so the AI triage verdict is ready and the email carries the AI's read (Likely REAL / Likely routine) instead of "Verdict pending" - and a false positive the AI would dismiss is quietened before it ever reaches your inbox. The same brief hold now applies to consolidated incident-card emails as well, so they too arrive with a settled verdict. The wait is bounded: if triage is slow or stuck, the email still sends rather than delaying a genuinely urgent alert. In practice this means fewer "Verdict pending" emails and less routine noise.

Body contents (in order):

• Tenant severity strip at the top - counts of distinct incidents (each user + category once, at its highest severity in the last 24 hours), NOT raw alert instances. The numbers match what an analyst would count on the Alerts page.
• AI triage badge - see below. Lets you rank your inbox at a glance.
• AI "why this matters" paragraph (2 to 4 sentences) - clearly labelled as AI, safety-checked. Since 2026-07-09 it is fed the rule's exact trigger (the specific guest, sensitive term, or count that crossed the threshold) so it states plainly why this alert fired, not just a generic description of the category - while still only using the values it was given.
• What actually happened · reconstructed from raw events - the investigation digest. A plain-English reconstruction of the user's day built entirely by code from raw audit events. Every bullet is deterministic and verifiable. This block is labelled "analysed by Burrow" rather than "Burrow AI" - deliberately, because it is code, not the language model, and an AI label would be a false claim about how it was produced.
• Key metrics / Event Details - the counters (bytes, distinct files, sites, geographies), each fact on its own line for scannability, including the Source IP country (registered) row that shows the registered country of each source IP (e.g. 211.144.19.102 = CN). The old "Location" row is now labelled SharePoint region (tenant, not user) so the datacenter region is never mistaken for the user's location. See Reading the evidence box.
• Plain-English rendering (2026-07-21). Every rule-engine trigger string in the email now reads as plain English - you see "1,953 manual download events", never a raw downloaded_manual=1953, and countries render by name with their code ("Maldives (MV)"). The raw machine values are still retained in the alert's underlying record for anyone who needs to pivot on them, but the email itself is written for a human.
• Top evidence - a sample of the underlying audit events.
• Link to the alert in the dashboard.

The body follows the same trust hierarchy as the drawer - an operator responding to an out-of-hours page can answer "what actually happened?" without needing to open the dashboard.

Subject pattern: [SEVERITY] category_name - user.upn@example.com

2. Consolidated incident card

When sent: the incident correlation engine detects a cluster of related alerts on the same identity within a short window (default at least 3 alerts spanning at least 2 distinct rule families within 30 minutes) AND the cluster's severity is at or above your Minimum severity gate.

Body contents:

• Header with severity, identity, and time-span of the cluster.
• AI attack-chain summary - an overview sentence, then one short line per event in chronological order, each starting with its time. Reworked from a single paragraph (2026-08-13), which had restated the timeline printed directly below it. The same structure is produced whether or not the AI is available, so the format does not change under load.
• A suggested next step, called out separately rather than buried in the narrative.
• Timeline of the constituent alerts (time, severity, category, summary for each).
• Link to the Investigation in the dashboard.

The incident card also carries the AI triage badge, reflecting the worst-case verdict across the constituent alerts.

Effect on per-alert emails: the per-alert emails for the cluster's constituent alerts are pre-empted. You get ONE email (the incident card) instead of N raw per-alert emails for the same cluster.

An incident only emails if it has something to consolidate (2026-07-31). If every alert in the cluster would have been silenced on its own - because each sat below your minimum-severity floor, or the AI dismissed it within your AI-suppression policy - then the incident card is silenced too, and the decision is journaled. This closes a gap where a cluster of individually-quiet alerts could arrive as one loud email that bypassed your severity floor entirely. A cluster containing even one alert that would have emailed on its own still emails as normal.

One action seen by several rules is not an escalation (2026-07-31). Several rules commonly fire on a single burst of activity - a new device, at a new hour, from a new country is one sign-in described three ways. When every alert in the cluster covers a read-only session (previews, page views, searches) with no data movement (nothing downloaded, changed, deleted, uploaded, or shared) and nothing sensitive touched, Burrow treats that as one cause rather than three corroborating signals: the consolidated incident is capped at Low and marked as a single-cause cluster, so it stays visible on the Cases page without paging anyone. The individual alerts are unaffected and still email on their own merits, so genuine read-only reconnaissance is still surfaced by whichever rule detected it.

3. Daily escalation summary

When sent: when the daily pattern detector scores a user's day and the cumulative score crosses the threshold. Score weights severity, category diversity, time spread, and slope.

Body contents:

• Header with the user and the day.
• AI narrative of the day's pattern.
• Escalation pattern table - every contributing alert in time order, with severity, category, and what it triggered on. Chronological, deterministic - an auditor can trace the sequence without the AI narrative.
• Severity = maximum of constituent severities, bumped one tier.

Effect on per-alert emails: once a daily escalation summary has been sent for a user-day, ALL further per-alert emails for that user for the rest of the day are suppressed (logged in the suppression journal with the dedup reason).

4. Weekly executive briefing

When sent: every Monday morning (around 06:00 local time) to recipients with the Weekly briefing gate enabled.

Body contents:

• Header tiles (alerts this week, week-over-week change, human Critical + High count, active incidents).
• AI-written 200 to 300 word narrative summarising the week's signal, top concerns, and recommended actions.
• Top entities table - human actors only.
• Top categories table - human actors only.
• A separate service-account summary line - the tenant's own automation (document-pipeline service principals) is excluded from the risk ranking and summarised here, so it can't headline as the top security risk. See Weekly executive briefing.

Subject pattern: Burrow weekly briefing - [tenant name]

Independent of the per-alert pipeline - a recipient with Minimum severity = Critical (no per-alert emails) still receives the weekly briefing if the Weekly briefing gate is on.

For full detail on the briefing, see Weekly executive briefing.

The AI triage badge

Since 2026-07-06, every per-alert email and incident card carries an AI triage badge near the top - the AI's verdict on whether the alert looks real, surfaced so you can rank your inbox without opening Burrow. The four states:

Badge	Meaning
Likely REAL - prioritise this one	The AI judged the alert genuine and worth priority attention.
Uncertain - needs human review	The AI could not confidently call it either way.
Likely routine for this user	The AI judged the activity normal for this user.
Verdict pending (triage running)	The email went out before the AI triage verdict was ready. Now rare - both per-alert emails and incident cards are held a few minutes for the verdict; you only see this when triage was slow or stuck and the bounded wait elapsed.

Why the AI says this (2026-08-13)

Underneath the verdict pill, per-alert emails and incident cards now carry a "Why the AI says this" box: the reasoning behind the verdict, not just the verdict. It names the evidence the AI actually weighed - the user's baseline, the geography, the working-hours pattern, whether the activity was platform machinery. On an incident card it also gives a one-line note for each other alert in the cluster, so you can see why the group was read as one story.

Shortcut dismissals are labelled as such. Not every verdict comes from a full AI review. Where an alert was dismissed on precedent, the box says so plainly - for example "recurring pattern for this user, 13 similar in 30 days - dismissed without full AI review". That distinction matters: a verdict reached by weighing this alert's evidence deserves more confidence than one reached by noticing it resembles previous alerts, and you can now tell which you are reading.

The reasoning is checked against the alert in front of you. Triage reasoning is cached and reused where alerts recur. If the cached reasoning was written about an earlier alert whose numbers differ from this one, the box says so rather than quoting figures that do not match. An explanation citing the wrong numbers is worse than no explanation, because it reads as authoritative.

The badge is advisory - severity remains the primary signal. The wording is deliberate: it never says "false positive", so a wrong verdict reads as an opinion to weigh, not permission to delete. On the incident card, the badge reflects the worst-case verdict across all constituent alerts.

Suppression layers - the order they apply

A per-alert email is sent only if it passes EVERY one of these checks. Each suppression is recorded in the suppression journal with a specific reason so an auditor can later see why anything was skipped.

1. Minimum severity floor. If the alert's severity is below your Min severity setting → skip.
2. Entity exception (Suppress). If the user matches an exception with action=Suppress → skip.
3. AI verdict not-real. If the AI triage step marked the alert "not real" → skip (default).
4. Rule-mode exclude list. If your Rules mode is Selected and the category is not on the list → skip.
5. Cooldown. If the same (user, category) pair already emailed within the last hour → skip.
6. Daily escalation dedup. If a daily escalation summary has already been sent for this user today → skip every subsequent per-alert email for that user for the rest of the day.
7. Incident card pre-emption. If this alert is a constituent of an Investigation that the consolidated incident card already covered → skip.

The result of these layers is the email volume reduction you experience day-to-day: 5+ alerts on one user become 1 incident card; 8+ alerts on one user across the day become 1 daily escalation summary; recurring alerts in the same hour get cooldown-suppressed.

What you can configure to change email volume

The fastest levers, in order of effect:

1. Raise the Minimum severity gate on the Settings page. Going from Medium to High typically cuts per-alert volume by 50%+ in a noisy week.
2. Add entity exceptions for known-noisy accounts. Each Suppress exception removes that user's alerts from every recipient's inbox.
3. Tune noisy rules via the Suggestions page (main nav → Tuning → Suggestions).
4. Switch Rules mode to Selected if specific categories are noisy. The recipient list then only emails the categories you opt them into.

What is NOT email

A few things you might expect to email but do not:

• Operator dispositions. When a SOC analyst marks an alert Real / Not real / Maybe, no email goes out. The change is reflected in the dashboard and logged on the History page.
• Admin configuration changes. When you add an exception, change the posture, or edit a rule, no email goes out. Logged on the History page.
• Catch-up alerts from an outage. When Burrow comes back from an audit collection outage, it back-fills historical alerts. The historical alerts DO send through the email pipeline subject to all the usual suppression layers - but the cooldown layer often dedups bursts, so you may see fewer emails than the raw alert count.

See also

• The investigation digest - the deterministic reconstruction card that leads every per-alert email.
• How an alert flows through Burrow - the full pipeline that produces these emails.
• Configuring alert email recipients - where to set the gates.
• Exporting the suppression journal - to see what was suppressed.

---

Need help? support@smikar.com.