no incidents generated since May 20?

[permafrost]

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.

[permafrost]

Thanks, already got near-identical responses from a couple of chat agents - and that didn't go anywhere.

Which chat agent was this?

[H.Eldessouki]

Claude Fable 5

[susekar]

Hello @permafrost ,

Greetings for the day.

Based on the symptoms you described—where Cortex XDR is successfully blocking threats on endpoints but is not generating incidents in the management console, while manual scans continue to generate incidents—the most likely causes are an Alert Exclusion configuration or changes to the incident creation or alert severity settings.

Since you mentioned that you are not the primary XDR administrator, the following checks can help identify the cause.

1. Check for Alert Exclusion Rules (Most Likely)

An Alert Exclusion allows the agent to continue blocking threats while preventing the corresponding alert from being reported to the management console. This aligns with your observation that threats are blocked but no incidents are created.

To verify:

1. Log in to the Cortex XDR console.
2. Navigate to Settings → Configurations → Alert Exclusions.
3. Review any active exclusion rules, especially those created or modified around the time the issue began.
4. Look for broad exclusions related to Malware or Prevented actions.
5. If an overly broad exclusion is found, temporarily disable it and verify the behavior using a known safe malware test file.

2. Verify the Alerts Table

Cortex XDR differentiates between Alerts (individual detections) and Incidents (groups of related alerts). Depending on your incident creation settings, lower-severity alerts may not be promoted to incidents.

To verify:

1. Navigate to Incident Response → Alerts.
2. Review alerts generated during the affected time period.
3. If detections appear in the Alerts table but not as incidents, review their severity and determine whether they meet the criteria for incident creation.

3. Review Management Audit Logs:

Management Audit Logs can help determine whether any policy or configuration changes were made around the time the issue started.

To verify:

1. Navigate to Settings → Audit Logs → Management Audit.
2. Filter the logs for the timeframe when the issue first occurred.
3. Review any changes related to policies, configurations, or alert exclusions.
   
   

4. Review Incident Creation Rules:

Incident creation rules determine which alerts are promoted into incidents.

To verify:

1. Navigate to Incident Response → Incident Configuration → Incident Creation Rules.
2. Confirm that the rules responsible for Malware or Analytics detections are enabled.
3. Verify that the incident creation criteria have not been restricted to only specific severity levels.

If all of the above settings appear to be configured correctly and the issue persists, we recommend collecting the relevant logs and opening a support case for further investigation.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar

[permafrost]

No AI responses please.

[permafrost]

Important few details (that seem to trigger AI slop in responses):

• no alerts either - i.e. it's not just about the incidents. ... and yes, I've checked exclusion rules and all filters including a sole "Excluded=Yes" one.
• The license is "Prevent" - which apparently restricts detection, blocking, telemetry and analytics - yet should not on its own prevent simple on-execution blocking (of a Palo-Alto-supplied sample designed to trigger alerts) from generating an alert.
• Kindly asking to please not copy-paste AI responses. (Been working on this for a few days, got plenty of AI slop already.)

(Can't seem to edit my post - else would have added all this to it.)

[sscalia]

Any chance you found a resolution on this? My tenant is having the same issue now. All I'm coming across are AI Slop answers and nothing substantial. IM Dashboard hasn't reported an incident in over a month and I'm an Account Admin level user. 

[permafrost · Accepted solution]

---

@sscalia wrote:

Any chance you found a resolution on this? My tenant is having the same issue now. All I'm coming across are AI Slop answers and nothing substantial. IM Dashboard hasn't reported an incident in over a month and I'm an Account Admin level user. 

---

Alas - no, except strongly suspecting:

• a backend issue, i.e. nothing on our side
• Palo Alto support not admitting it and instead instructing their support people to blame everything on the tenant

Reason why I am suspecting that:

• No response from PAN Support to my several requests on the mechanism to detect this issue. E.g. how to scan local XDR logs for events indicating an alert should have been fired, so we could cross-reference that with what's in the console. I'd literally ask them, "what about that mechanism I asked about before?" and they would just ignore it like I didn't ask anything.
• Non-sensical, strange responses about alert exclusions - and that - after the ticket was escalated to someone who didn't use AI slop. E.g. they said excluded alerts don't show up in the console after the first one that was excluded - yet fully ignore the absence of that first alert in the "excluded alerts" table.
• No response to my repeated questions about the overall picture - that we had a lot of users report XDR pop-ups about malware blocked yet no alerts at all for over a month. They keep insisting on providing them with full support files for specific endpoints and after those were provided, they'd respond with how this is normal and expected. Just surreal. 😂

I have recommended to switch XDR providers to my management. Almost anything is better than this.

[sscalia]

I'm about there as well. Palo support & documentation seems lacking lately. I would wager it is something on the backend they changed and are not admitting to.