no incidents generated since May 20?

[Alex.Gerulaitis]

Our Cortex XDR instance stopped generating incidents when detecting malware and other threats. (Somewhat similar to "Cortex XDR - Blocked Hashes on newer systems do not show in Incidents" - except in our case, this is across the board on all devices, for all threats and behaviors.)

(If we initiate a malware scan on the affected device, an incident is generated 🟢 for the same file that was previously blocked by Cortex with no incident. I.e. this tells us the incident creation system is not broken - rather, the usual mechanism of creating incident upon detection or blocking is not working for some reason.)

The first assumption is that something has changed on our side - i.e. we accidentally created a policy (or deleted or disabled an existing policy) - which killed the incident generation mechanism.

The 2nd - that something has changed on the back end w/o our involvement resulting in the above change of behavior.

This seems to have occurred sometime in May 2026.

• The last auto-generated incident was on May 20 with no such incidents since.
• Usually we get at least a few incidents a week - so this is unusual.
• Several users reported blocking by Cortex XDR in late May and early June - but no incidents.
• No known changes that could have resulted in this change of behavior on our side. (That said, can't rule out an accidental change.)
• Initiating a malware scan on the machine on which malware was detected or blocked - resulted in incidents generated for the same files that were blocked.

In either case - where do we go to try to figure out what happened, when, and how to fix it? (Please be gentle and patient - Cortex XDR is just a small part of things on my plate, and I will likely not understand something like "go fix your BIOCs".)

Thank you!

[H.Eldessouki]

Given what you're describing ---> still getting blocked in real time, zero incidents, but a manual scan on the same file does produce one — that points at something suppressing the alert from ever being saved, not a broken detection engine. Check these in order:

1. Settings → Exception Configuration → Alert Exclusions. Sort by Modification Date, look for anything touched around May 15–20. This is my top suspect: an Alert Exclusion rule suppresses matching alerts from being saved/shown in the console (and from creating incidents) — but the agent keeps enforcing the block locally on the endpoint regardless. That's exactly your symptom. If the exclusion criteria happens to only match real-time detections and not on-demand scan results, that also explains why your manual scan still produces an incident for the same file.

2. Settings → Management Auditing. Filter the date range to May 15–20 and Type = "Alert Exclusions" / "Alert Rules" / "Prevention Policy Rules" / "Rules Exceptions". This log keeps 365 days of every admin change with enough detail to see exactly what changed and roll it back. This settles "did we do this to ourselves" either way.

3. Settings → Health Alerts (or Incident Response → Incidents → Alerts Table → switch the view to "Health Domain"). Look for a Correlation-type health alert around your cutoff date — that means the rule that turns detections into incidents is failing silently. Right-click it → "Investigate Correlation Auditing" to see which one broke. Also check for an Ingestion-type alert, which would mean the underlying data feed itself dropped.

If none of the three show anything, open a TAC case with one blocked-but-no-incident file hash + endpoint + timestamp, plus the manual-scan counter-example — that combination is specific enough that support can go straight to the backend pipeline instead of starting from scratch.