Lesson 34 — Troubleshooting an Analytics Rule That Didn't Fire
The activity happened.
The logs are there.
The analytics rule was enabled.
But no alert appeared.
What you will learn
Find where a failed detection path actually broke.
Learning objectives
- Use a repeatable workflow when an expected Sentinel alert is missing.
- Separate missing data from faulty detection logic.
- Validate rule frequency, lookup period and ingestion timing.
- Distinguish a successful rule run with no alert from a failed rule execution.
- Use Microsoft Sentinel health data to investigate execution problems.
The investigation
A security engineer deliberately generated activity that should have matched a scheduled analytics rule.
The event can be found in Log Analytics. The rule is enabled. The expected alert never appears.
Where do you start?
Do not treat “no alert” as one problem
| What happened | What it means |
|---|---|
| The source event never arrived | The detection had nothing to evaluate. |
| The event arrived but the query did not match it | The detection logic or time window excluded it. |
| The query returned results below the configured threshold | The rule ran successfully but did not generate an alert. |
| The rule execution failed | The detection pipeline attempted to run but encountered an execution problem. |
| The alert exists but was grouped or handled differently than expected | The detection fired, but the analyst looked in the wrong place or expected different incident behaviour. |
The troubleshooting path
Step 1 — prove the evidence exists
Start with the table the analytics rule depends on. Do not assume the connector delivered the event simply because the source system generated it.
Microsoft's current Sentinel troubleshooting guidance begins with verifying data availability and freshness.
Use the smallest useful query
Search directly for the known test event using identifiers you trust: account, IP address, device, operation, correlation ID or an exact UTC time range.
If the evidence is absent, stop troubleshooting the analytics rule and investigate ingestion first.
Example — verify the sign-in evidence
- 1
- 2
- 3
- 4
SigninLogs | where TimeGenerated between (datetime(2026-09-26 00:00:00) .. datetime(2026-09-26 01:00:00)) | where UserPrincipalName =~ "testuser@contoso.com" | project TimeGenerated, UserPrincipalName, IPAddress, ResultType
The dates and account above are examples. In a real investigation, use the exact UTC period and entity values from your test.
Step 2 — run the rule KQL manually
Copy the analytics rule query into Logs and run it against the period containing the known event.
If the source event exists but the rule query returns nothing, work through every filter, join, summarize, watchlist lookup and function until you identify where the row disappears.
Reduce the query carefully
Remove conditions one at a time. Do not delete half the query and declare it fixed.
Testing one condition at a time preserves the evidence trail and tells you exactly which assumption failed.
Step 3 — reproduce the rule's actual time window
A manual query returning the event over seven days does not prove a rule looking back 30 minutes could see it.
| Setting | Question to ask |
|---|---|
| Run query every | When did Sentinel execute the detection? |
| Lookup data from the last | Was the event inside the data window evaluated by that run? |
| Event timestamp | What is the event's TimeGenerated? |
| Ingestion time | Had the event reached the workspace when the rule executed? |
Scheduled analytics rules use their configured interval and lookback. The interval must be less than or equal to the lookback, and overlapping periods can evaluate some data more than once.
Step 4 — consider ingestion delay
An event can have the correct TimeGenerated value and still arrive in the workspace after the relevant rule execution.
Microsoft Sentinel deliberately delays scheduled rule execution by five minutes to help account for ingestion latency, but some sources can take longer.
Measure instead of guessing
For supported workspace data, compare TimeGenerated with ingestion_time() to understand how long the data took to arrive.
If latency is longer than the detection design allows, the rule's lookup strategy may need adjustment.
Example — inspect ingestion delay
- 1
- 2
- 3
- 4
- 5
- 6
- 7
SigninLogs
| where TimeGenerated > ago(1d)
| extend IngestionTime = ingestion_time()
| extend IngestionDelay = IngestionTime - TimeGenerated
| project TimeGenerated, IngestionTime, IngestionDelay,
UserPrincipalName, IPAddressStep 5 — check the alert threshold
A query can return exactly the evidence you expected and still produce no alert if the analytics rule's configured result threshold was not reached.
Microsoft Sentinel health records distinguish successful executions that generated alerts from successful executions that did not reach the threshold.
Watch for double thresholds
Your KQL might already contain where FailedAttempts >= 20, while the rule wizard separately requires more than one returned result.
Understand both layers. A threshold that made sense during testing can quietly suppress a production alert.
Step 6 — inspect analytics rule health
If health and audit monitoring is enabled for the workspace, Microsoft Sentinel records analytics rule execution health in the SentinelHealth table. Microsoft recommends the _SentinelHealth() function for queries because it helps maintain compatibility with schema changes.
- 1
- 2
- 3
_SentinelHealth() | where SentinelResourceType == "Analytics Rule" | where SentinelResourceKind == "Scheduled"
Health events can show whether the rule succeeded or failed, why it failed, how many events the query captured and whether the threshold was reached.
Health data must be enabled
If _SentinelHealth() returns nothing, do not immediately conclude that no rule runs occurred.
Auditing and health monitoring must first be enabled for the workspace, with the appropriate analytics-rule logs sent to Log Analytics.
Check the rule itself
Confirm the rule is enabled and that nobody changed its query, schedule, threshold or status.
If audit monitoring is enabled, _SentinelAudit() can help identify analytics rule changes and who made them.
Common execution failures
| Health evidence | Investigation direction |
|---|---|
| Table not found | Verify the data source and referenced table. |
| Function not found | Confirm required functions or parsers exist in the workspace. |
| Syntax or semantic error | Validate the rule query and referenced fields. |
| Query timed out / excessive resources | Review KQL efficiency and the amount of data processed. |
| Delayed due to ingestion | Review data latency and the rule's lookup design. |
| Success but threshold not reached | The rule ran; investigate query results and threshold configuration. |
Scheduled rules have retry behaviour
Microsoft documents that when a scheduled analytics rule execution fails, Sentinel retries that same window up to five additional times.
A single failed execution can therefore mean a delay rather than a permanently missed detection. Health data lets you distinguish transient failures from a window where all attempts failed.
Use rule execution insights
Where available, the analytics rule Insights experience can show failed executions, health issues and alert activity for a selected rule.
Microsoft also provides manual rerun capability for scheduled analytics rules as a preview feature, useful for testing and troubleshooting specific historical execution windows.
Step 7 — did the alert fire after all?
Before changing the detection, search for the alert and related incident.
Incident grouping can combine multiple alerts. Automation can change incident status or assignment. An analyst may therefore expect a brand-new incident while the alert has actually been added to existing investigation context.
First prove whether the alert was generated. Then determine what happened to it.
Common mistake — testing with a huge time range
The analyst runs the query over 30 days, sees the test event and concludes Sentinel should have alerted.
Reproduce the exact rule window. The scheduled detection did not have 30 days of hindsight.
Common mistake — changing five things
The threshold, query, lookup, grouping and exceptions are all changed at once.
If the alert then fires, nobody knows which change fixed it — or which change weakened the detection.
Common mistake — blaming KQL first
The KQL may be perfectly correct while the data arrived late, the rule was disabled, a required parser disappeared or the execution failed.
Troubleshoot the whole detection path.
Common mistake — ignoring health monitoring
A SOC can spend hours manually diagnosing failures that Sentinel has already recorded in its health telemetry.
Operational detections need operational monitoring.
Agent Foskett investigation exercise
You generate 12 failures at 10:02. The events appear in SigninLogs, but there is no alert.
- Confirm the exact 12 source events and their timestamps.
- Run the production KQL over the exact period.
- Check the rule frequency and lookup period.
- Compare
TimeGeneratedwith ingestion time. - Check the KQL and rule-level thresholds.
- Review
_SentinelHealth()for the relevant execution. - Confirm the rule was enabled and unchanged.
- Search for an existing alert or grouped incident before modifying the detection.
Best practices
- Start with evidence availability.
- Reproduce the exact rule query and execution window.
- Check ingestion delay when timing matters.
- Understand both KQL and rule-level thresholds.
- Enable and use Sentinel health and audit monitoring.
- Change one variable at a time.
- Record the root cause, not just the fix.
Agent Foskett takeaway
A missing alert is not evidence that “Sentinel failed.”
Find the last point in the detection pipeline where the evidence still exists, then inspect the next step.
The logs already knew. Your job is to find where the rule stopped listening.
Related Agent Foskett learning
Continue learning
Troubleshoot a Microsoft Sentinel Analytics Rule That Did Not Fire
Missing Microsoft Sentinel alerts can result from absent or delayed source data, query logic, rule scheduling and lookback windows, thresholds, execution failures, disabled rules, or alert and incident handling. A structured investigation isolates each stage before the detection is changed.
Microsoft Sentinel Lesson 34
This Agent Foskett Microsoft Sentinel Academy lesson teaches a practical troubleshooting workflow using source evidence, KQL, ingestion timing, analytics rule configuration, SentinelHealth and audit information.
