Lesson 22 — Building Scheduled Analytics Rules in Microsoft Sentinel
Microsoft Sentinel can collect enormous amounts of security telemetry, but collecting evidence is only the beginning.
A scheduled analytics rule repeatedly runs a KQL query across a defined lookback period and turns matching results into security alerts when the rule conditions are met.
In this lesson, we move beyond the first analytics rule and build a detection deliberately: query first, then schedule, threshold, enrich, group and validate.
What you will learn
This lesson shows how the major parts of a scheduled analytics rule work together to create a useful detection.
Learning objectives
After completing this lesson, you should be able to explain and design the core components of a Microsoft Sentinel scheduled analytics rule.
- Explain how scheduled analytics rules turn KQL results into alerts.
- Build and validate the detection query before creating the rule.
- Understand query frequency and lookup period.
- Use alert thresholds and event grouping deliberately.
- Enrich alerts with entities and useful investigation context.
The problem this solves
A useful hunting query does not automatically become a useful detection.
A production analytics rule must decide when to run, how far back to look, what constitutes a match, what evidence the analyst sees and how the resulting alerts become incidents.
What is a scheduled analytics rule?
A scheduled analytics rule runs a KQL query at a configured interval against a defined lookback period.
If the returned results meet the configured alert threshold, Microsoft Sentinel can generate one or more alerts and feed those alerts into the incident workflow.
Do not begin with the rule wizard. Begin with the behaviour you want to detect and prove that the KQL reliably finds it.
The detection pipeline
Start with a detection hypothesis
Before writing KQL, describe the behaviour in plain language.
A user account generating repeated failed sign-ins from the same IP address within a short period may indicate password guessing or automated credential attacks.
The hypothesis gives the query a purpose. It also makes later tuning easier because you can ask whether each condition helps detect the behaviour you originally cared about.
Build and test the KQL
Use the Logs experience to build and test the query before placing it into an analytics rule.
This example groups failed Microsoft Entra sign-ins by user and IP address:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
SigninLogs
| where ResultType != "0"
| summarize FailedSignIns = count(),
StartTime = min(TimeGenerated),
EndTime = max(TimeGenerated)
by UserPrincipalName, IPAddress
| where FailedSignIns >= 10
In a real environment, tune the query against normal activity and confirm the fields you intend to use for alert enrichment are present in the final results.
Rule name and description
Give the rule a name that tells an analyst what behaviour was detected.
The description should explain the detection logic, why the behaviour matters and any important assumptions or limitations.
Severity and MITRE ATT&CK
Choose severity based on the detection's security significance and expected response, not simply because the activity looks unusual.
Map relevant MITRE ATT&CK tactics and techniques where they accurately describe the behaviour being detected.
Run query every
The query frequency controls how often the scheduled rule executes.
Microsoft Sentinel supports scheduled intervals from 5 minutes to 14 days. More frequent execution can improve detection latency but also increases query activity.
Lookup data from the last
The lookup period defines how much historical data each execution examines.
It must be at least as long as the query frequency. A longer lookup period can overlap previous executions, so the detection logic must be designed with duplicate results in mind.
Frequency and lookback work together
| Setting | Example | What it means |
|---|---|---|
| Run query every | 15 minutes | Sentinel evaluates the rule four times per hour. |
| Lookup data from the last | 30 minutes | Each execution examines the previous 30 minutes of data. |
| Result | 15-minute overlap | Some events can appear in more than one execution unless the detection design accounts for the overlap. |
Ingestion delay matters
Events are not always available in the workspace immediately after they occur.
Microsoft Sentinel accounts for ingestion latency in scheduled rule execution, but analysts should still understand the data source's normal delay when designing and troubleshooting detections.
Alert threshold
The alert threshold determines how many query results are required before the rule generates an alert.
A threshold should reflect the detection logic. One highly significant event may be enough, while other behaviours become meaningful only after repeated activity.
Event grouping
Scheduled rules can group all returned events into a single alert or generate an alert for each result.
Choose the model that makes the resulting alert understandable and actionable for the analyst who receives it.
Incident grouping
Alerts can be grouped into incidents based on rule settings and correlation behaviour.
In the Microsoft Defender portal, the unified correlation engine can also influence how alerts are correlated into incidents, so do not assume that every rule execution maps one-to-one with an incident.
Entity mapping
Map fields returned by the query to recognised entities such as accounts, IP addresses, hosts, URLs or files.
Good entity mapping gives Sentinel investigation features useful objects to pivot on instead of leaving important evidence buried in raw query output.
Custom details
Custom details surface selected query fields directly in the alert.
Use them for evidence an analyst is likely to need immediately, such as counts, source values, application names or other context that explains why the alert fired.
Dynamic alert details
Alert details can use query output to make properties such as the alert name or description more specific to the event.
Used carefully, this can make the queue much easier to triage because the analyst sees useful context before opening the alert.
Automation comes later
Do not rush to attach automated response to a detection that has not been validated.
First prove that the rule fires when expected, produces useful evidence and has an acceptable false-positive rate. Then decide whether automation is appropriate.
Agent Foskett workflow
Test before enabling
- Run the KQL across representative historical data.
- Confirm expected true-positive examples are returned.
- Review normal activity that might create false positives.
- Confirm entity fields and custom details are populated.
- Check the expected query volume and performance.
Validate after enabling
- Confirm the rule executes successfully.
- Verify alerts contain the expected evidence.
- Inspect entity mapping and incident presentation.
- Check whether grouping behaves as intended.
- Record tuning decisions and rule ownership.
Common mistake
A common mistake is copying a hunting query into an analytics rule and enabling it without considering scheduling.
A query that works perfectly across seven days of hunting data may behave very differently when it runs every 15 minutes.
Another common mistake
Do not return only the minimum field needed to trigger the detection.
The analyst who receives the alert needs enough context to understand what happened and decide what to investigate next.
Agent Foskett investigation tip
Open the alert as if you were the analyst seeing it at 2:17 AM. If the evidence does not immediately help you decide what to investigate next, improve the rule.
Best practices
- Design the detection around a documented security behaviour.
- Test the KQL independently before creating the rule.
- Choose frequency and lookback deliberately.
- Return fields that support investigation and entity mapping.
- Tune with evidence rather than simply suppressing noise.
- Assign ownership and periodically review production rules.
Agent Foskett takeaway
A scheduled analytics rule is more than a KQL query on a timer.
Good detection engineering combines reliable query logic with sensible scheduling, useful enrichment, deliberate grouping and continuous validation.
Related Agent Foskett learning
Continue learning
Building Scheduled Analytics Rules in Microsoft Sentinel
Microsoft Sentinel scheduled analytics rules use KQL queries, query frequency, lookback periods, thresholds, entity mapping, custom details and grouping settings to turn security telemetry into actionable alerts.
Microsoft Sentinel Lesson 22
This Agent Foskett Microsoft Sentinel Academy lesson explains how to design, test, enrich, enable and validate scheduled analytics rules for practical security detection engineering.
