Lesson 28 — Near-Real-Time (NRT) Analytics Rules
Some detections can wait five or ten minutes. Others should not.
If an attacker is actively changing privileges, abusing an account or executing suspicious activity, detection speed can change the investigation.
Microsoft Sentinel near-real-time analytics rules are designed to run every minute and bring detection much closer to the moment the data arrives.
What you will learn
Learn how NRT rules differ from scheduled rules and when faster detection is worth using.
Learning objectives
After completing this lesson, you should understand when and how near-real-time analytics rules are used.
- Explain what an NRT analytics rule is.
- Understand its fixed one-minute schedule and lookback.
- Explain why NRT rules use ingestion time.
- Recognise important NRT limits.
- Choose between NRT and scheduled detection appropriately.
The investigation
An attacker has obtained an account and begins making security-sensitive changes.
A detection that waits several minutes may still work — but for activity where every minute matters, the SOC wants the signal as quickly as Sentinel can reliably evaluate the ingested data.
What is an NRT analytics rule?
A near-real-time analytics rule is a highly responsive Microsoft Sentinel analytics rule designed to provide up-to-the-minute threat detection.
NRT rules run automatically once every minute and evaluate data ingested during the preceding minute.
NRT does not mean magic. The event still has to reach Sentinel before Sentinel can detect it.
How NRT detection flows
The schedule is fixed
Unlike a scheduled analytics rule, you do not choose the query frequency for an NRT rule.
The query is automatically scheduled to run every minute with a one-minute lookback period.
No alert threshold setting
NRT rules do not expose the normal scheduled-rule alert threshold setting.
When the NRT query produces a result, an alert is generated. If your detection needs threshold logic, design that logic into the KQL itself.
Scheduled rule versus NRT rule
| Design area | Scheduled analytics rule | NRT analytics rule |
|---|---|---|
| Query frequency | Configurable | Fixed at once per minute |
| Lookback period | Configurable | Fixed one-minute lookback |
| Alert threshold | Configurable | No separate threshold setting |
| Primary purpose | Flexible detection scheduling and context | Fast detection of recently ingested activity |
| Event grouping | Supports normal scheduled-rule behaviour | Available with NRT-specific limits |
The ingestion-delay problem
Events are not always ingested at exactly the moment they occur.
A rule that relies only on source event time can miss late-arriving data if the event falls outside the query's time window by the time it becomes searchable.
NRT uses ingestion time
NRT rules address this problem by evaluating events according to when they were ingested rather than relying on the source event's TimeGenerated value for scheduling.
This lets the rule focus on data that has actually arrived in Sentinel during its detection window.
Event time and ingestion time are different
Measure ingestion delay with KQL
- 1
- 2
- 3
- 4
CommonSecurityLog | extend IngestionTime = ingestion_time() | extend IngestionDelay = IngestionTime - TimeGenerated | project TimeGenerated, IngestionTime, IngestionDelay
This is useful when deciding whether a data source is suitable for a fast detection. NRT cannot detect data before the data has been ingested.
There is still a built-in delay
Microsoft documents a minimum built-in delay of approximately two minutes for NRT rules.
The important point is that NRT shortens the detection cycle; it does not mean the alert appears at the exact instant the source event occurs.
Use the right data source
NRT rules are designed for data sources that arrive quickly enough for near-real-time detection to be useful.
Microsoft states that NRT rules only work properly on log sources with an ingestion delay of less than 12 hours — but a source delayed by hours clearly defeats the operational purpose of NRT.
NRT still supports investigation context
Near-real-time does not mean stripped-down alerts. NRT rules support many of the capabilities you already used in this module.
| Capability | NRT support |
|---|---|
| Multiple tables in the query | Supported |
| Watchlists | Supported |
| Entity mapping | Supported |
| Custom details | Supported |
| Dynamic alert details | Supported |
| Incident grouping | Supported |
| Automation rules and playbooks | Supported |
| Multiple workspaces | Supported |
NRT rule limits
Microsoft currently allows 50 enabled NRT rules per customer, with 100 NRT rules in total including disabled rules.
NRT rules are counted separately from scheduled analytics rules.
Event grouping has a smaller limit
If an NRT rule is configured to generate an alert for each event, it can produce up to 30 alerts from a rule execution.
If more than 30 events are returned, the first 29 produce individual alerts and the 30th alert summarises the applicable result set.
Keep the result focused
Microsoft recommends using project so the NRT query returns only the fields the alert actually needs.
Returning unnecessary columns increases alert payload size and can cause useful information to be truncated.
- 1
- 2
- 3
- 4
SigninLogs | where ResultType != "0" | where UserPrincipalName == "alex@contoso.com" | project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName
When NRT makes sense
Use NRT when the behaviour is time-sensitive and detecting newly ingested activity quickly provides real operational value.
Examples can include security-sensitive identity changes, high-impact administrative activity or other detections where reducing detection latency improves response.
When scheduled may be better
Not every detection benefits from running every minute.
Rules that need longer behavioural windows, broader aggregation, baselining or context collected over time may be better suited to scheduled analytics rules.
Do not choose NRT because it sounds faster
Does this behaviour need a one-minute detection cycle, and does the source data arrive quickly enough for that speed to matter?
If the answer is no, a well-designed scheduled rule may be simpler and more appropriate.
Common mistake — expecting true streaming
Sentinel NRT analytics rules evaluate events after they have been ingested.
They are near-real-time analytics, not a promise that the rule examines an event at the source before ingestion.
Common mistake — ignoring ingestion delay
A rule can run every minute while its data arrives much later.
Measure the source's actual ingestion behaviour before assuming NRT will materially reduce end-to-end detection time.
Common mistake — using NRT everywhere
Faster is not automatically better detection engineering.
Use NRT for detections that genuinely benefit from rapid evaluation rather than converting every scheduled rule simply because the option exists.
Common mistake — returning everything
An NRT query that carries every source column into the alert can create unnecessary payload and obscure the fields that matter.
Return the evidence required for entities, enrichment and investigation.
Agent Foskett investigation exercise
Detection A looks for a critical administrative action where the SOC wants to know within minutes. Detection B looks for unusual behaviour accumulated across several hours.
Detection A is a natural NRT candidate if the required telemetry is ingested quickly and the query fits NRT behaviour.
Detection B is likely better suited to a scheduled rule because its detection logic depends on a broader observation window.
Best practices
- Use NRT for genuinely time-sensitive detections.
- Understand the data source's ingestion delay.
- Remember the fixed one-minute execution and lookback.
- Keep query output focused with
project. - Preserve entity mapping and useful alert enrichment.
- Test the end-to-end detection time, not just the query.
Agent Foskett takeaway
NRT rules shorten the gap between data ingestion and detection by evaluating newly ingested activity every minute.
Use that speed where it changes the response. A one-minute rule detecting three-hour-old telemetry is still three hours late.
Related Agent Foskett learning
Continue learning
Near-Real-Time NRT Analytics Rules in Microsoft Sentinel
Microsoft Sentinel near-real-time analytics rules run once every minute with a one-minute lookback to provide faster detection of newly ingested security events while supporting entity mapping, custom details, incident grouping and automation.
Microsoft Sentinel Lesson 28
This Agent Foskett Microsoft Sentinel Academy lesson explains NRT scheduling, ingestion time, detection latency, NRT rule limits, event grouping and practical decisions for choosing NRT versus scheduled analytics rules.
