DE1.6 Alert Grouping and Incident Architecture

Alert grouping is configured on the Incident settings tab of the analytics rule wizard. It's the final configuration decision before you deploy a rule, and the one most frequently left on the default — which is no grouping at all. The default means every alert creates a new incident. For a rule that fires frequently against the same entity, the default floods the queue with duplicate investigations.

Understanding alert grouping requires distinguishing it from a related but separate concept: event grouping. These two mechanisms operate at different stages of the pipeline and control different things.

Estimated time: 40 minutes.

Event grouping recap

Event grouping was introduced in Section 1.2. The two modes determine what happens within a single rule execution:

Group all events into a single alert — the default. All result rows from one execution are bundled into one alert. If your brute force query returns 3 users who exceeded the threshold, you get one alert with all 3 users' data inside it. This mode is appropriate when the results collectively represent a single incident.

Trigger an alert for each event (AlertPerResult) — each result row produces its own alert. If your query returns 3 users, you get 3 separate alerts. This mode is appropriate when each result row represents an independent finding. For the brute force rule, each user is a separate compromised account requiring its own investigation, so AlertPerResult is the correct choice.

There's a limit: AlertPerResult produces a maximum of 150 alerts per execution. If the query returns more than 150 rows, the first 149 events generate individual alerts and the 150th alert summarizes the remainder. This is a safety valve against noisy rules flooding the alert pipeline.

Alert grouping — the incident architecture

Alert grouping operates across executions over time. It answers the question: when the rule fires again 15 minutes later and detects the same entity, should Sentinel create a new incident or add the alert to an existing incident for that entity?

The three grouping criteria

Group all alerts into a single incident. Every alert from the rule — regardless of which entities are involved — goes into the same incident within the time window. Use this when the rule detects a single type of activity that always represents the same investigation, regardless of the specific entities. Example: a rule that monitors for changes to a specific critical security group. Every alert about that group is part of the same investigation.

Group if all entities match. Alerts are grouped into the same incident only when every mapped entity in the new alert matches every mapped entity in an existing incident. If your rule maps Account and IP entities, both must match for grouping to occur. A new alert for s.chen from IP 185.234.72.14 groups with an existing incident for s.chen from 185.234.72.14, but creates a new incident if the IP differs. This is the most conservative entity-based option — it requires complete entity alignment.

Group if selected entities match. You choose which entity types drive the grouping. If you select Account only, alerts are grouped when the Account entity matches — regardless of whether the IP differs. s.chen from 185.234.72.14 and s.chen from 91.215.85.xx group into the same incident because the Account is the same. This is the recommended approach for most detection rules — you want all alerts about the same user or host in one incident, even if the source IPs change (which they often do during an attack as the attacker switches infrastructure).

The time window

The time window determines how long Sentinel keeps an incident "open" for new matching alerts. The range is 5 minutes to 7 days. The default is 5 hours.

A 5-hour window means that if the rule fires at 10:00 and creates an incident for s.chen, any matching alert generated before 15:00 gets added to the same incident. An alert at 15:30 creates a new incident. A 24-hour window keeps the incident open for a full day — appropriate for attacks that unfold over hours, like the brute force scenario in the opening.

The trade-off is context vs manageability. A 7-day window consolidates a week of related alerts into a single incident with complete context but creates incidents with dozens of alerts that can be overwhelming to investigate. A 5-hour window creates more incidents but each is contained. For most detection rules, 24 hours strikes the right balance — most attacks either succeed or are detected within a day, and the analyst gets a complete timeline without excessive accumulation.

Reopening closed incidents

If an incident is resolved and closed, and a new matching alert arrives later, Sentinel can either create a new incident or reopen the closed one. This setting exists because attacks sometimes resume — the analyst closes the brute force incident, but the attacker returns 6 hours later with a different approach.

Enabling reopening keeps the investigation thread intact — all related alerts stay in one incident, even if there was a gap. Disabling it creates a clean new incident, which is useful if the SOC wants each investigation to have a defined start and end.

One important constraint: if you've onboarded Sentinel to the Defender portal, the alert grouping settings you configure are treated as initial instructions. The Defender XDR correlation engine makes its own decisions about alert correlation based on its broader cross-product context. Your settings influence but don't fully control the outcome.

The 150-alert limit

An incident can contain a maximum of 150 alerts. If the grouping criteria would add a 151st alert, Sentinel creates a new incident with identical details and groups the excess alerts into it. This limit exists to keep incidents investigable — an incident with 300 alerts is a queue problem, not an investigation.

If your detection rules regularly hit this limit, the rule is either too broad (detecting too much legitimate activity) or the grouping window is too long. Both are signals for tuning.

Configure alert grouping on your test rule

Open your brute force test rule. Navigate to the Incident settings tab.

1. Create incidents from alerts: Enabled (this should already be set).
2. Alert grouping: Enabled.
3. Limit the group to alerts created within: 24 hours.
4. Group alerts triggered by this rule into a single incident by: If the selected entities match.
5. Select entity: Account.
6. Re-open closed matching incidents: Disabled (for now — you can enable this after you've evaluated the pattern in your environment).

This configuration means: when the brute force rule fires and detects s.chen@contoso.com, Sentinel checks whether an open incident from this rule already exists with s.chen as the Account entity. If yes, the new alert is added to the existing incident. If no, a new incident is created. The 24-hour window means the grouping remains active for a full day.

The Account entity was chosen as the grouping criterion because the Account is the constant in a brute force attack — the attacker targets a specific user. The source IP may change (the attacker rotates infrastructure), the failure count may vary (different password lists), but the target account stays the same. Grouping on Account ensures all alerts about the same compromised account are consolidated regardless of which IPs are involved.

How event grouping and alert grouping interact

The two mechanisms chain together. Here is the full sequence for your brute force rule:

10:00 — Rule executes. The query finds 2 users (s.chen and j.park) with brute force patterns. Event grouping is set to AlertPerResult, so 2 alerts are generated — one per user. Alert grouping checks for existing incidents: none found. Two new incidents are created: Incident A (s.chen) and Incident B (j.park).

10:15 — Rule executes again. The query finds s.chen still under attack. Event grouping produces 1 alert for s.chen. Alert grouping finds Incident A still open (within the 24-hour window) and the Account entity matches. The new alert is added to Incident A. No new incident created.

10:30 — Rule executes again. The query finds s.chen with a successful sign-in following the brute force. Event grouping produces 1 alert. Alert grouping adds it to Incident A. The analyst now sees 3 alerts in Incident A's timeline: the initial brute force at 10:00, the continued attack at 10:15, and the successful compromise at 10:30.

This is what a detection engineer designs — not just a query that detects an event, but a pipeline that produces an investigable incident with complete context over time.

Query your current incidents to see the grouping impact — how many incidents per rule, and how many have duplicate investigations:

// Are your incidents fragmented? How many per rule?
SecurityIncident
| where TimeGenerated > ago(30d)
| summarize
    Incidents = count(),
    AvgAlerts = round(avg(AlertsCount), 1)
    by Title
| sort by Incidents desc
| take 5

Title                                    Incidents  AvgAlerts
───────────────────────────────────────  ─────────  ─────────
Impossible travel activity               34         1.0
Suspicious inbox rule creation           22         1.0
Password spray detected                   8         1.0
MFA failure threshold                     6         1.2
Suspicious PowerShell execution           5         1.0

AvgAlerts = 1.0 across the board means no alert grouping is configured — every alert creates a new incident. The 34 impossible travel incidents are 34 separate investigations for what is likely 5–8 recurring patterns (VPN users, field engineers, specific travel routes). With entity-based grouping on Account, those 34 incidents collapse to 8 — one per affected user, each with a timeline showing the pattern.

Here's the alert grouping configuration as a JSON structure — the format used in ARM templates and detection-as-code pipelines:

{
  "incidentConfiguration": {
    "createIncident": true,
    "groupingConfiguration": {
      "enabled": true,
      "reopenClosedIncident": false,
      "lookbackDuration": "PT24H",
      "matchingMethod": "Selected",
      "groupByEntities": ["Account"],
      "groupByAlertDetails": [],
      "groupByCustomDetails": []
    }
  }
}

This is what the portal wizard produces — but in the template format that detection-as-code pipelines deploy. Understanding the JSON structure matters because in DE10, you'll deploy rules through Git, and the grouping configuration is part of the ARM template that defines the complete rule.