Purview audit log: why events are late, missing or already gone

The Purview audit log is where every investigation starts, and it is the first thing to let you down when the event you know happened is not there. Either the record has not arrived yet, or it was never recorded for that user, or it has already aged out. The search screen shows all three the same way, as an empty result, and the fix is different for each.

Most of the causes come back to licensing: who holds E5, which tenants audit by default, and how long each licence keeps a record. That makes this the audit side of Microsoft Purview cost, where the same licence cliffs decide the bill. Every Microsoft fact below was checked against Microsoft Learn on 26 September 2026.

How long before an event shows up in the Purview audit log

For core services Microsoft gives a typical range and then declines to promise it. The Search the audit log article states that for Exchange, SharePoint, OneDrive and Teams, audit record availability is typically 60 to 90 minutes after an event occurs, and that for other services it might be longer. The same article states that Microsoft doesn’t guarantee a specific time after an event for the record to be returned in a search.

That second sentence is the one to quote back to anyone asking for an incident timeline built on the audit log. There is no service level on the page, and none should be implied. Treat anything under two hours as normal and anything longer as a question about the specific service, not about the audit pipeline as a whole.

Is auditing actually on? The check that lies to you

Auditing is not on everywhere by default. Microsoft’s Turn auditing on or off article states that auditing isn’t enabled by default for Small and Medium Business licences, including Microsoft 365 Business Basic, Business Standard and Business Premium, and that unmanaged tenants on free trials of enterprise licences don’t have it enabled by default either. In both cases someone has to turn it on.

The obvious way to check gives the wrong answer in one of the two PowerShell modules. The same article warns that although Get-AdminAuditLogConfig is available in Security & Compliance PowerShell, the UnifiedAuditLogIngestionEnabled property there is always False, even when auditing is turned on. Run the check in Exchange Online PowerShell.

1# Run in Exchange Online PowerShell, not Security and Compliance PowerShell.
2# In Security and Compliance PowerShell this property always reads False.
3Connect-ExchangeOnline
4Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
5
6# Only if it reads False. Microsoft says this can take up to 60 minutes
7# to take effect, and events can take several hours to become searchable.
8Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Do not expect it to backfill. Nothing in the documentation suggests records are created for activity that happened before ingestion was enabled, and the retention policies that could have kept them are explicitly not retroactive. Assume the gap is permanent and write it into the case notes.

The failure modes

Each row below produces the same symptom in the Purview audit log: an event you are sure of that the search does not return.

The first row is the one that wastes most time, because it looks like a licensing bug and is documented behaviour. Microsoft’s audit troubleshooting scenarios article sets it out: even with mailbox auditing on by default, mailbox audit events return only for E5 users in the unified audit log, and the workaround is Set-Mailbox -Identity <mailbox> -AuditEnabled $true per mailbox. The article adds that if the mailbox already shows auditing enabled and searches still return nothing, you change the value to False and then back to True. That toggle is not something anyone guesses.

Retention by licence: what you keep, and what you cannot get back

The audit log retention policies article describes the default policy in Audit (Premium). It retains Exchange Online, SharePoint, OneDrive and Microsoft Entra audit records for one year, and records for all other activities for 180 days unless a custom policy says otherwise. Non-E5 users and guest users are retained for 180 days.

Two traps sit in that table. First, a retention policy is not retroactive: Microsoft’s audit solutions overview states that the 10-year policy can’t retain logs generated before the policy was created. Buying the add-on after an incident keeps nothing from before the purchase. Second, the licence that matters is the user’s, not the tenant’s. A tenant with E5 for the security team and E3 for everyone else keeps one year of mailbox evidence for a few people and 180 days for everyone else, and the person under investigation is rarely in the security team. The licence arithmetic is laid out in Microsoft 365 E3 vs E5.

Portal, PowerShell or an export: which one to trust

The portal search covers a maximum date range of 180 days per search, keeps completed search jobs for 30 days, and shows an approximate count once a query returns more than 100,000 results. It requires the Audit Logs or View-Only Audit Logs role in the Purview portal. It is the right tool for a first look and the wrong one for evidence, because the count is approximate and the export is capped.

PowerShell is better for evidence, provided you remove the defaults that hide data. Always set -ResultSize, use -HighCompleteness, and page with ReturnLargeSet. Record the exact command you ran in the case notes, because the same search without those parameters returns a different and smaller answer. If the evidence then goes to a hold or a review set, eDiscovery in Microsoft 365 is where it lands. Check ingestion before a rollout such as sensitivity labels, where you will want a record of who changed what.

What I would do differently

I have not run an incident investigation against this tenant’s Purview audit log. It is a lab, so the judgement below comes from the documentation, not from a case.

Check ingestion on day one of any tenant you inherit, in Exchange Online PowerShell. It costs one command, and the alternative is discovering during an incident that nothing was recorded.

Decide audit retention before an incident, by user, not by tenant. List the roles whose activity you would need a year later: administrators, finance approvers, anyone with access to regulated data. Make sure those people hold the licence that keeps a year. The retention policies cannot reach back, so the decision only has value if it is made early.

Treat the portal count as an estimate and the export cap as a hard edge. Any audit evidence that matters should come from a scripted PowerShell search with the completeness switch, run twice, with both outputs kept. If the two runs disagree, that is itself a finding worth writing down.

Last verified: 26 September 2026