Missed Microsoft Defender Alerts? Here Is Why It Happens and How to Fix It

Many teams say the same thing after an incident: “We have Defender. Why did we still miss the alert?”

In practice, missed alerts usually come from a small set of repeatable causes. A notification rule was not created for the thing you are watching. The rule exists, but its filters or scope exclude what you care about. Notifications arrive late because of correlation timing or routing delays. Or the notification arrives just fine, but nobody reliably sees it and takes ownership.

This post is a practical checklist for diagnosing which of those is happening and fixing it. If you are looking for the broader discussion of why email-based alerting breaks down as an operational workflow, we cover that separately in why email-based Defender alerting fails. This post is about the configuration and process side.

Start here: identify your failure mode

Before changing any settings, identify which type of failure you are actually dealing with. These look similar from the outside but have very different fixes.

What “missed alerts” actually means

Before changing any settings, it helps to identify which type of failure you are dealing with. Four different things get described as “missed alerts,” and the fix for each is different.

The first is that no notification was sent at all. The rule is missing, scoped too narrowly, filtered by severity, or blocked by permissions. This is a pure configuration issue and usually the easiest to fix once you know where to look.

The second is that a notification was sent, but it arrived late. The incident was created well after the underlying activity, or your routing chain introduced enough delay that the notification felt stale by the time it arrived. This is partly how Defender works and partly how your notification pipeline is built.

The third is that the notification was sent and arrived on time, but nobody noticed it. Email noise, chat noise, no acknowledgement mechanism, no escalation, and no clear owner. This is a workflow failure rather than a configuration failure, and we cover it in more depth in the email alerting post.

The fourth is that the Defender portal itself looks empty or incidents appear to be missing. Filters, permissions, or tenant state changes can make it look like incidents and alerts have disappeared when they have not.

The rest of this post walks through each one with specific things to check and fix.

Confirm you configured the right notification type

This is the single most common configuration mismatch, and it trips up teams regularly.

Microsoft Defender has two separate notification systems: alert notifications and incident notifications. They are configured in different places in the security portal, they cover different event types, and setting up one does not automatically cover the other. Many teams set up incident notification rules, assume they are covered, and then discover that important alerts that have not yet been grouped into an incident never triggered a notification.

To fix this, start by understanding which security events you actually care about and whether they surface as alerts, incidents, or both. If your team primarily works the incidents queue, that is a reasonable operational choice, but you should still verify alert notification coverage for cases where an alert does not become an incident quickly. Some alerts sit in the queue for a while before Defender's correlation engine groups them into an incident, and during that window, an alert-only notification might be your earliest signal.

Check both notification configurations. Confirm the recipients, severity filters, and scope for each. The distinction is well-documented in Microsoft Learn, but it catches people out often enough that it deserves to be the first thing on any troubleshooting checklist. For a full setup walkthrough, see how to configure Defender for Endpoint email notifications.

When “test email works” but real detections do not notify

This pattern shows up frequently in community discussions. The test message arrives successfully, which makes it look like everything is configured correctly, but real incidents or alerts never produce a notification. There are several common reasons for this, and working through them in order saves time.

Severity filters exclude what you are testing

If your notification rule is set to notify only on High or Critical severity, you will never see notifications for meaningful Medium-severity activity. Some test scenarios also do not produce events at the severity level you expect, which means the test passes but real-world activity falls outside the filter.

The fix is to temporarily set the rule to notify on all severities while you are validating the pipeline. Confirm that notifications trigger for a real incident or alert in your environment, not just the test button. Once you have validated end-to-end delivery, tighten the severity filter back to what makes sense for your team.

Scope or device groups exclude where the event happened

Notification rules can be scoped to specific device groups or contexts. This works well until something changes: devices move between groups, new machines are onboarded, Intune group memberships shift, or someone reorganises the Defender device grouping structure. When that happens, events from devices that are no longer in scope simply do not produce notifications.

Confirm the rule applies to all relevant device groups. If you use multiple groups, verify which group the impacted device actually belongs to, because the answer is sometimes surprising after an onboarding or reorganisation change. Make it a habit to re-check scope after any changes to device groups, Intune assignments, or Defender grouping configuration.

Permissions and roles create visibility gaps

Two administrators can see different things in the Defender portal depending on their role and RBAC configuration. You can end up in a situation where you believe a notification rule is active and correctly configured, but your access level limits what you can actually verify or what the rule covers.

Validate that the account managing notifications has the appropriate security admin permissions. If possible, compare what the notification configuration looks like from a different admin account. RBAC issues are particularly easy to miss because the portal does not always make it obvious that your view is filtered.

You are expecting every blocked action to notify

Not every blocked or remediated event in Defender becomes an alert or incident that matches your notification rules. Defender blocks a significant amount of activity automatically, and only a subset of those actions generate security alerts. This is by design, but it leads to a common confusion: “Defender caught the malware, why was I not notified?”

If you are investigating a specific missed notification, first confirm that the activity actually produced a Defender alert or incident. If it did, check whether the rule filters match its severity and source. If the activity was blocked but never created an alert, that is expected behaviour for many types of automatic remediation. Focus your notification rules on the signals that genuinely require a human response rather than trying to notify on everything Defender handles autonomously.

Check alert tuning before blaming notifications

Microsoft Defender XDR has a built-in alert tuning system that most admins do not think to check until they have exhausted every other option. These rules can hide alerts from view, auto-resolve them before you ever see them, or classify signals as behaviors rather than security alerts. If you run a test, expect an alert, and see nothing in the queue, this is often why.

Alert tuning rules come in two types. Built-in rules are maintained by Microsoft and are designed to reduce false positives from specific detection sources. Custom rules are created by your organisation to suppress noise from known-benign activity in your environment. Both types can silently consume an alert before it reaches the Alerts queue or triggers a notification.

To review alert tuning rules:

1. Go to Microsoft Defender portal → Settings → Microsoft Defender XDR → Alert tuning.
2. Review both the built-in and custom rule lists.
3. Look for rules with an action of Hide alert, Resolve alert, or Set as behavior.
4. If you suspect a specific rule is consuming a test detection, temporarily disable that rule while you validate, then re-enable or refine it after testing.

If you are testing with EICAR, validate the right thing

The EICAR test file is a standard, harmless file that Defender Antivirus will detect and remove. It is a quick way to confirm that AV scanning is active on a device. It is not a reliable way to validate the full Defender XDR alert, incident, and notification pipeline.

Understanding what EICAR proves and what it does not prove saves a lot of confusion:

• What an EICAR detection proves: Defender Antivirus is running and scanning on the endpoint. The device's real-time protection is active.
• What it does not prove: the endpoint is onboarded to Defender for Endpoint; EDR telemetry is flowing to the Defender XDR service; a Defender XDR alert was generated; that alert was correlated into an incident; a notification rule matched the alert or incident; the notification was delivered to a recipient.

Each of those steps is separate. A device can have Defender AV running and detecting EICAR while being completely unmonitored by Defender for Endpoint — if it is not onboarded, no EDR telemetry flows to the cloud service, and no XDR alert is generated regardless of what AV does locally.

Additionally, even on a properly onboarded device, Defender AV detections do not always create Defender XDR security alerts. Automatic remediation of a known test file may be handled without surfacing as an alert. Alert tuning rules can also intercept the signal before it appears in the queue.

For a proper end-to-end validation of the Defender for Endpoint detection and reporting pipeline, use Microsoft's official onboarding detection test rather than EICAR:

1. In the Defender portal, go to Settings → Endpoints → Onboarding.
2. Follow the “Run a detection test” instructions for your onboarding method.
3. The script generates telemetry that specifically tests EDR reporting and creates a Defender XDR alert if the device is correctly onboarded and reporting.
4. Confirm the alert appears in the Alerts queue, that an incident is created, and that your notification rules trigger for it.

EICAR is useful for AV validation. The official detection test is what you need for XDR pipeline validation.

When notifications arrive hours late

Late notifications are frustrating because they undermine trust in the entire alerting system. If people learn that Defender notifications routinely arrive after the fact, they stop relying on them and fall back to manual portal checks, which is not sustainable.

There are two common causes, and they compound each other.

Incident creation lags behind the underlying alerts

Defender's correlation engine groups related alerts into incidents, but that correlation takes time. An alert might fire within minutes of suspicious activity, but the incident that groups it with other signals may not be created until significantly later. If your notification rules are set up for incidents rather than alerts, your earliest notification is delayed by the correlation window.

This is not a bug. It is how incident correlation is supposed to work, and the resulting incident is usually more informative than the raw alert. But if your priority is speed over completeness, consider monitoring the alert stream as your primary trigger for urgent notifications, with incident notifications as the second layer for context.

Your routing chain adds its own delay

The path from Defender to the person who needs to respond is often longer than it looks. Email forwarding rules, Microsoft Teams connectors, ticketing system integrations, Logic Apps, Azure Functions, or custom automation all introduce their own latency. Worse, when one link in the chain fails or retries, the delay can be significant and hard to diagnose.

Map the full path from Defender notification to human response. Identify every intermediate system along the way. Add monitoring or logging to the automation itself so that failures are visible rather than silent. A notification pipeline that breaks without telling you is arguably worse than no pipeline at all.

When the portal looks empty or incidents appear missing

Sometimes “missed alerts” is not a notification problem at all. The portal appears to be missing data, which makes it look like Defender is not detecting anything.

The most common cause is a time range filter. If the portal is set to show the last 24 hours and the incident you are looking for was created two days ago, it is not visible. This sounds obvious, but it catches people out regularly, especially when switching between views or returning to the portal after a weekend.

Other causes include viewing the wrong workload or section within the portal, permissions or licensing changes that affect data visibility, or tenant-level changes that altered what data is available. If the portal looks unexpectedly empty, check the time filters first, then confirm your role has the needed security visibility. Comparing the view with another admin account is the quickest way to separate RBAC issues from UI or service-level issues.

If only some devices miss alerts, check sensor health

When alerts are generated for some devices but not others, the problem is usually not with your notification rules — it is with the devices themselves. A device that is onboarded but unhealthy will not generate reliable EDR telemetry, which means alerts from that device simply do not appear.

Work through these checks for the affected devices:

• Device appears in the portal. Go to Assets → Devices. If the device is not listed, it is either not onboarded or the onboarding package did not complete successfully.
• Device health status is Active. A device showing as Inactive, Impaired communications, or No sensor data is not reporting telemetry correctly. Impaired communications usually means connectivity to Defender service URLs is blocked. No sensor data often means the SENSE service is not running or the onboarding registration failed.
• SENSE service running. On Windows, the Windows Defender Advanced Threat Protection Service (SENSE) must be running. If it is stopped or disabled, no telemetry reaches the cloud service regardless of other settings.
• Proxy and connectivity. Defender for Endpoint requires connectivity to specific Microsoft service URLs. If devices route through a proxy or have strict firewall rules, verify that required endpoints are reachable via WinHTTP. Microsoft's documentation lists the current required service URLs.
• Policy application. Confirm that Defender AV and EDR policies are applied via Intune, Group Policy, or your configuration management tool. Conflicting or missing policies may result in EDR being disabled on affected devices.
• Device group membership. Confirm the device belongs to a group covered by your notification rules. Onboarded devices placed in an uncovered group will generate alerts that never trigger notifications.

If Defender for Identity alerts are missing

Defender for Identity (MDI) monitors Active Directory and Azure AD for identity-based attacks. Its alerts surface in Defender XDR when the integration is active, but missing MDI alerts are often not a notification configuration problem — they are an integration or threshold issue.

Check these before adjusting notification rules:

• MDI integration with Defender XDR. In the Defender portal, go to Settings → Identities and confirm the MDI sensors are healthy and connected. If the MDI workspace is not linked to your Defender XDR tenant, identity alerts will not appear in the unified queue.
• Integration with Defender for Cloud Apps. Some MDI alert types only flow through Defender for Cloud Apps. If you are expecting cloud identity alerts, confirm the Cloud Apps integration is also enabled.
• Alert thresholds. MDI has configurable sensitivity thresholds for some detection types. If thresholds are set conservatively, genuine attacks may fall below the trigger level. Review threshold settings under Settings → Identities.
• Test mode. MDI has a learning mode for some detections during initial deployment. Confirm it is not active in a production environment if you are expecting real alerts to fire.

If alerts show in Defender but not Sentinel or ticketing

When alerts are visible in the Defender portal but do not appear in Microsoft Sentinel, your ITSM, or your ticketing workflow, the problem is almost always in the pipeline between Defender and the destination — not in Defender itself.

Sentinel connector state

Go to Microsoft Sentinel → Data connectors and check the status of the Microsoft Defender XDR connector. If it is disconnected or showing errors, data has stopped flowing. Re-authorising the connector usually resolves sync issues.

Once the connector is active, verify data is actually arriving by querying the SecurityAlert, SecurityIncident, AlertInfo, and AlertEvidence tables in Log Analytics. Confirm records have recent timestamps.

Sentinel incident creation rules

When you enable the Defender XDR connector with incidents sync, Microsoft recommends disabling Sentinel's own incident creation rules for Defender XDR-sourced products to prevent duplicate incidents. If those rules were disabled as part of setup and you are now expecting Sentinel incidents, that is the likely cause of missing incidents.

Review your active analytics rules and automation rules. Confirm which rules are intentionally disabled for deduplication and which ones should be producing incidents.

Logic Apps, webhooks, and ticketing integrations

If Sentinel is receiving data but your ticketing system is not, the break is in the automation layer. Common failure points to check:

• Logic App run history — failed runs, timeouts, or throttling in the execution log
• Webhook endpoint returned an error that stopped retries
• Ticketing rule filtering out the alert by severity or status — verify filter conditions match what you expect to route
• Azure Function exceptions not surfaced in alerts — check Application Insights or function execution logs
• Authentication credentials expired for the ticketing system connector

Advanced Hunting checks

When you need to confirm what Defender actually recorded — regardless of whether notifications fired — Advanced Hunting gives you direct access to the raw telemetry. These queries run in the Microsoft Defender portal under Hunting → Advanced Hunting and are useful for verifying whether an alert was generated, what evidence was collected, and whether your test even reached the XDR layer at all.

Recent alerts across all detection sources

Run this to see what Defender has generated in the last 24 hours. If an alert appears here but you never received a notification for it, the problem is in your notification rules or routing — not in detection.

AlertInfo
| where Timestamp > ago(24h)
| project Timestamp, Title, Severity, ServiceSource, DetectionSource, Category, Status
| order by Timestamp desc

Search for a specific test or alert type

If you are looking for a specific event — an EICAR test, a phishing simulation, or a known alert title — use this to check whether it reached the XDR alert layer at all over the last seven days.

AlertInfo
| where Timestamp > ago(7d)
| where Title has_any ("EICAR", "malware", "phish", "suspicious")
| project Timestamp, Title, Severity, ServiceSource, DetectionSource, Status, AlertId
| order by Timestamp desc

Evidence tied to recent alerts

If an alert was generated and you want to see what evidence was associated with it — devices, accounts, files, URLs — this query shows the evidence table for the last seven days.

AlertEvidence
| where Timestamp > ago(7d)
| project Timestamp, AlertId, EntityType, DeviceName, AccountName, RemoteUrl, FileName, SHA256
| order by Timestamp desc

If AlertInfo returns results for a detection but you did not receive a notification, go directly to your notification rules and validate scope, severity filter, and recipient list.

A 15-minute audit checklist

Here is a condensed checklist you can work through in about 15 minutes. It covers the three things that matter: coverage, timeliness, and ownership.

Coverage

• Confirm you have incident notification rules configured with the correct recipients and severity filters
• Confirm you have alert notification rules configured separately, covering the alert types that matter most to your team
• Verify that severity filters match what you actually want to be notified about, not just High and Critical
• Verify that scope includes all relevant device groups and workloads, and re-check after any onboarding or group changes
• Review alert tuning rules (Settings → Microsoft Defender XDR → Alert tuning) for Hide, Resolve, or Set as behavior actions
• Confirm that end-to-end validation used the official MDE detection test, not only EICAR
• Check device health for any device that appears to have missed alerts: sensor status, SENSE service, proxy connectivity

Timeliness

• Understand whether the earliest signal for your scenarios appears as an alert before it becomes an incident
• Inspect your routing chain for delays, retries, and silent failures
• Confirm your automation pipeline has monitoring so you know when it breaks
• If using Sentinel, confirm the Defender XDR connector is active and tables are receiving recent data

Ownership

• Define who owns acknowledgement for high-severity events
• Define an escalation path if nobody acknowledges within a specific time window
• Separate informational notifications from urgent ones so the urgent channel does not become background noise

Can SOC Anywhere fix this?

SOC Anywhere helps teams see and act on Defender alerts faster. It does not generate Defender alerts, fix connector configurations, or replace Sentinel. Being honest about what it does and does not do is more useful than overclaiming.

Problem	Defender configuration fix?	SOC Anywhere helps?
No alert was generated	Yes — fix device onboarding, alert tuning, or AV policy	No — SOC Anywhere does not generate Defender alerts
Alert generated but notification rule excluded it	Yes — fix notification rule scope and filters	No — this is a Defender configuration issue
Alert generated but email was missed	Partially — you can change the delivery channel	Yes — native iOS and Android push notifications instead of email
Alert arrived but nobody acknowledged it	No — Defender notifications are fire-and-forget	Yes — built specifically to solve acknowledgement and ownership
Incident created late due to correlation	Partially — add alert notifications for earlier signal	Partially — reduces time-to-acknowledge, not time-to-create
Sentinel or ticketing workflow silently failed	Yes — fix the connector, Logic App, or automation rule	No — SOC Anywhere is separate from Sentinel pipelines

When configuration is correct but alerts still get missed

If you have worked through this checklist and your Defender configuration is sound, the remaining problem is usually the notification channel itself. Email and chat can reliably deliver notifications, but they cannot ensure that someone sees the notification, acknowledges it, and takes action within a reasonable time. That is a workflow problem, not a configuration problem.

The things you want at that point are real-time delivery to the right person, clear acknowledgement and ownership so the team knows who is handling what, and the ability to triage quickly from a phone without opening a laptop. If you are interested in the deeper discussion of why email fails as an operational alerting channel, the email alerting post covers it in detail.

For teams that have solved the configuration side and need to solve the workflow side, SOC Anywhere was built for that gap. It provides real-time Defender incident notifications with a mobile-first triage workflow, so you can acknowledge and respond quickly regardless of where you are or what time it is.

Frequently asked questions

Why does the Microsoft Defender test email work but real alerts do not arrive?

The test email bypasses all notification rule filters and fires unconditionally to confirm that email delivery works. Real alerts must match your rule's severity filters, workload scope, and device group scope before a notification is triggered. A passed test only confirms email delivery; it does not confirm your filters will match the signals you care about.

Does every Defender Antivirus detection create a Defender XDR alert?

No. Many Defender AV detections — particularly files that are automatically blocked or quarantined — are handled without generating a Defender XDR security alert. Only activity that crosses specific detection thresholds or requires analyst attention surfaces in the Alerts queue.

Why did EICAR get removed but no Defender incident was created?

EICAR confirms that Defender Antivirus is scanning — nothing more. AV detection does not always generate a Defender XDR alert, and an alert does not always result in a correlated incident. Each step is separate. Use Microsoft's official MDE onboarding detection test to validate the full XDR pipeline.

Where are Microsoft Defender XDR alert tuning rules?

Microsoft Defender portal → Settings → Microsoft Defender XDR → Alert tuning. Both Microsoft-maintained built-in rules and your organisation's custom rules are listed there. Look for actions set to Hide alert, Resolve alert, or Set as behavior.

Can Defender XDR auto-resolve alerts?

Yes. Both built-in tuning rules and custom rules can be configured to automatically resolve matching alerts before you act on them. If alerts are disappearing before you see them, check alert tuning rules for auto-resolve actions.

Why are Defender alerts missing from Sentinel?

Most commonly: the Defender XDR data connector is disconnected or stopped syncing; Sentinel's incident creation rules for Defender XDR products were disabled to avoid duplicate incidents; or a Sentinel automation rule is filtering alerts before they create incidents. Check connector status in Data connectors and query the SecurityAlert and SecurityIncident tables directly.

Why can one admin see alerts but another cannot?

Role-Based Access Control in Defender scopes what each admin can see. One account may be limited to a specific device group or workload while another has global read. Compare active roles and device group scope for both accounts. The portal does not always make it obvious that a view is RBAC-filtered.

What is the difference between Defender alert notifications and incident notifications?

Alert notifications fire when a new security alert is created, before correlation into an incident. Incident notifications fire when an incident is created or updated by the correlation engine. Alert notifications are faster but carry less context; incident notifications carry more context but arrive later. For full setup details, see configuring Defender email notifications.

Related Articles

• Why Email-Based Defender Alerting Fails
• Configure Defender for Endpoint Email Notifications
• How to Get Real-Time Notifications from Microsoft Defender for Endpoint
• Mobile Security Operations: Handling Defender Incidents on the Go
• SOC Anywhere vs ITSM Integrations for Microsoft Defender for Endpoint