Lesson 24 — Setting Alert Thresholds in Microsoft Sentinel
A scheduled analytics rule can return security events without automatically creating an alert.
The alert threshold tells Microsoft Sentinel how many query results must be returned before the rule should generate an alert.
By understanding thresholds, analysts can tune detection sensitivity without confusing the number of query rows with values calculated inside the KQL itself.
What you will learn
This lesson explains how alert thresholds control when scheduled analytics rule results become Microsoft Sentinel alerts.
Learning objectives
After completing this lesson, you should understand how alert thresholds affect Microsoft Sentinel scheduled analytics rules.
- Explain what the alert threshold evaluates.
- Understand minimum, maximum and exact result thresholds.
- Distinguish query result counts from values calculated inside KQL.
- Understand how scheduling can change threshold behaviour.
- Use results simulation and historical evidence when tuning.
The problem this solves
Not every matching event should become an alert.
Thresholds let a scheduled analytics rule decide whether the number of results returned during that execution is significant enough to generate one.
What is an alert threshold?
When a scheduled analytics rule runs, Microsoft Sentinel executes the KQL query and counts the results returned by that query.
The alert threshold compares that result count with a configured number. If the condition is met, the rule generates an alert.
The threshold counts query results. It does not automatically inspect a number stored inside one of those results.
How the threshold fits into the rule
Greater than
A greater-than threshold is useful when activity becomes important only after the query returns more than a defined number of results.
For example, generate an alert when the number of query results is greater than 50.
Less than
A less-than threshold can detect situations where unusually low activity has security meaning.
This is less common in basic threat detections, but it can be useful when a normal process or expected security signal suddenly disappears.
Equal to
An exact threshold generates an alert when the number of returned query results matches the configured value.
Exact-count logic should be used carefully because real-world activity can vary significantly.
Threshold zero
A common configuration is to generate an alert when the number of query results is greater than zero.
In this design, the KQL performs the important filtering and the rule alerts whenever at least one significant result remains.
Example threshold outcomes
| Query results | Threshold condition | Outcome |
|---|---|---|
| 37 rows | Greater than 0 | Alert generated |
| 37 rows | Greater than 20 | Alert generated |
| 37 rows | Greater than 50 | No alert |
| 37 rows | Equal to 37 | Alert generated |
| 37 rows | Less than 10 | No alert |
The threshold applies to each run
The threshold is evaluated separately every time the scheduled analytics rule executes.
Sentinel does not automatically add the result counts from several executions together before applying the threshold.
Scheduling matters
The query frequency and lookup period determine which records are examined during each execution.
Changing the lookup period can therefore change the number of results and whether the configured threshold is reached.
KQL threshold versus Sentinel threshold
Detection logic can include thresholds inside the KQL itself as well as in the analytics rule configuration.
| KQL threshold | Sentinel alert threshold |
|---|---|
| Evaluates values and conditions inside the query. | Evaluates how many rows the final query returns. |
| Can group events by account, IP address or device. | Counts the final result set from the rule execution. |
| Example: FailedSignIns >= 10. | Example: Generate alert when query results > 0. |
Failed sign-in example
- 1
- 2
- 3
- 4
SigninLogs | where ResultType != "0" | summarize FailedSignIns = count() by UserPrincipalName, IPAddress | where FailedSignIns >= 10
This query returns only account and IP combinations that have already reached the KQL threshold of ten failed sign-ins.
The analytics rule could then generate an alert when the number of query results is greater than zero.
The 742 failed sign-ins case
If the Sentinel alert threshold is configured to generate an alert only when the number of query results is greater than 100, this result does not meet that condition.
Why analysts get caught
The value inside a result can look like the obvious threshold value.
But after summarize, hundreds or thousands of raw events may become only one final query row.
Inspect the final output
Before setting the Sentinel threshold, run the query and inspect the final result table.
Ask how many rows are returned and what each row represents.
Event grouping
After the threshold is met, event grouping controls how the query results are turned into alerts.
You can group all events into a single alert or trigger an alert for each returned event.
Alert-per-event limit
For scheduled rules using alert-per-event grouping, Microsoft Sentinel can generate up to 150 alerts from a rule execution.
If more than 150 events are returned, the first 149 generate individual alerts and the 150th alert summarises the complete result set.
Results simulation
The scheduled analytics rule wizard can simulate the rule against current data using the configured schedule.
The simulation shows the results that the query would have produced over the previous 50 rule executions.
Use simulation before enabling
Results simulation can reveal that a proposed threshold would generate alerts too frequently or not at all.
Change the query, schedule or threshold and test again before deploying the rule.
Practical threshold tuning workflow
Baseline normal activity
Run the detection over representative historical periods before choosing a production threshold.
Normal activity can vary by time of day, business process, maintenance window and user population.
Do not tune for silence
Raising a threshold until the alerts disappear can make the queue quieter while weakening the detection.
The objective is to improve signal quality without removing the attacker behaviour the rule was created to find.
Suppression is different
A threshold decides whether the current query results should generate an alert.
Rule suppression can temporarily stop the query after an alert is generated. It solves a different problem and should not be confused with threshold tuning.
Document the threshold
Record why the threshold was selected, what data was tested and what behaviour the value is intended to identify.
A future analyst should not have to guess why a production rule contains a particular number.
Common mistake
A common mistake is confusing an aggregated field value with the number of query results.
Always inspect the final KQL output before configuring the Sentinel alert threshold.
Another common mistake
Do not choose a threshold from one short sample of data.
Test across representative periods so normal variation does not become a permanent source of false positives.
Agent Foskett investigation tip
If a rule does not fire when you expected it to, inspect the final query result set before changing the threshold. The number you are looking at inside a column may not be the number Sentinel is counting.
Best practices
- Understand exactly what each query result represents.
- Use KQL to express behaviour-specific thresholds where appropriate.
- Test the rule with its real query schedule and lookup period.
- Use results simulation before production deployment.
- Tune with evidence and document every significant change.
Agent Foskett takeaway
Alert thresholds are simple settings with major consequences for detection quality.
The key is knowing whether you are counting raw events, aggregated KQL values or final query rows — because Sentinel's rule threshold acts on the final query result count.
Related Agent Foskett learning
Continue learning
Setting Alert Thresholds in Microsoft Sentinel
Microsoft Sentinel scheduled analytics rules use alert thresholds to determine when the number of query results returned during an execution should generate a security alert.
Microsoft Sentinel Lesson 24
This Agent Foskett Microsoft Sentinel Academy lesson explains query result thresholds, KQL aggregation, event grouping, results simulation, tuning and practical threshold investigation techniques.
