air investigation stuck in pending state for a user-reported phishing cluster
Fixes Automated Investigation and Response investigations stuck in Pending for a user reported phishing cluster by clearing the approval, licensing, or evidence blockers. Use when an AIR investigation never progresses in Defender. Not for investigations that completed with a no action verdict.
TL;DR
Unstick the investigation at the step it is actually waiting on: open the investigation detail, read which action is pending approval or which evidence step stalled, approve or assign the pending remediation if it is correct, and check that the required Defender plan and permissions cover automated investigation for that workload. AIR pauses by design when a consequential action needs a human, and a queue of stuck investigations is usually a queue of unreviewed approvals, not a broken engine.
air investigation stuck in pending state for a user-reported phishing clusterUse this when
- An AIR investigation for a reported phishing cluster sits in Pending for hours or days.
- Related investigations for other clusters complete normally.
- Remediation actions inside the investigation show as awaiting approval.
Not for this skill when
- No investigation was created at all for the reports. That is a trigger or licensing problem at creation, not a stuck investigation.
- The investigation completed and took no action. Review its verdict logic instead of its state.
Steps
- Open the stuck investigation and list its state, its pending actions, and the evidence steps it completed. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the exact waiting point inside the investigation is named
- If actions await approval, review the proposed remediation against the cluster evidence and approve or reject it with a note. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the pending actions show a decision recorded by a named analyst
- Check the roles of the team meant to approve: confirm they hold a role that can approve AIR actions and can see the investigation queue. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: an approver role assignment is confirmed for the triage team
- Look for a stalled evidence step, such as a device or mailbox search that errored, and rerun or close that step per portal guidance. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the stalled step shows a completed or clearly failed state after action
- Watch the investigation to completion and record the total time from report to remediation for the campaign file. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the investigation reaches a completed state with actions recorded
Why it happens
Automated Investigation and Response is intentionally semi autonomous: it gathers evidence itself, then waits for a person before doing things like removing mail or isolating accounts, depending on your automation level. Investigations therefore stick in Pending for organisational reasons far more often than technical ones: nobody owns the approval queue, approvers lack the role, or the automation level was set to require approval for exactly the action the cluster needs.
Variants and edge cases
air investigation stuck pending user reported phishing cluster defender
The exact stuck state wording from the portal.
automated investigation pending approval not progressing office 365
The approval queue variant.
defender air investigation pending hours approve remediation action
The action oriented variant for analysts clearing the queue.
Compatibility: Microsoft Defender for Office 365 AIR, automation levels, and security operations roles.
Edge cases to check:
- Set a daily approval queue review during campaign season; stuck investigations age out in value quickly.
- Full automation for well understood actions like soft deleting reported phish reduces pending queues, but only enable it deliberately.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_4mEk6us-hpuZOO0j97lbWQ