Microsoft 365/Azure AD audit logs and reports latency data

As for some reason Microsoft keeps systematically removing useful information out of their official documentation, I figured I’d start keeping track on some of the more interesting bits. In this case, the latency at which audit logs and report data is being updated, i.e. how often said data is being refreshed.

Azure AD audit logs latency

Let’s start with the data on latency for Azure AD sign-in/audit logs events. This information was published as part of the Azure AD reporting latencies document, which was originally captured by the Wayback machine in Dec 2020, with timestamp showing May 2019 as the edit date. The latest capture of the document dates Oct 2022, and some point later it was replaced/merged with the current SLA performance document, which no longer includes info on latency.

Here’s the data on latency the original document featured:

Report Latency (95th percentile) Latency (99th percentile)
Audit logs 2 mins 5 mins
Sign-ins 2 mins 5 mins

Latency (95th percentile) refers to the time by which 95% of the logs will be reported, and Latency (99th percentile) refers to the time by which 99% of the logs will be reported.

Azure AD Reports latency

If we expand the search to also include documentation on reports, as opposed to just audit log events, an even older source can be found on GitHub. As its latest version dates all the way back to Mar 2016, not much of the information presented therein in still relevant. Just in case, here’s the data:

Report Minimum Average Maximum
Security Reports
Irregular sign-in activity 2 hours 4 hours 8 hours
Sign-ins from unknown sources 2 hours 4 hours 8 hours
Sign-ins after multiple failures 2 hours 4 hours 8 hours
Sign-ins from multiple geographies 2 hours 4 hours 8 hours
Sign-ins from IP addresses with suspicious activity 2 hours 4 hours 8 hours
Sign-ins from possibly infected devices 2 hours 4 hours 8 hours
Users with anomalous sign-in activity 2 hours 4 hours 8 hours
Users with leaked credentials 2 hours 4 hours 8 hours
Application Reports
Account provisioning activity 2 hours 4 hours 8 hours
Account provisioning errors 2 hours 4 hours 8 hours
Application usage 2 hours 4 hours 8 hours
Password rollover status 2 hours 4 hours 8 hours
Audit & Activity Reports
Audit report 1 minute 15 minutes 30 minutes
Password reset activity (Azure AD) 2 hours 4 hours 8 hours
Password reset activity (Identity Manager) 2 hours 4 hours 8 hours
Password reset registration activity (Azure AD) 2 hours 4 hours 8 hours
Password reset registration activity (Identity Manager) 2 hours 4 hours 8 hours
Self service groups activity (Azure AD) 2 hours 4 hours 8 hours
Self service groups activity (Identity Manager) 2 hours 4 hours 8 hours
RMS Reports
Most active RMS users 2 hours 4 hours 8 hours
RMS usage 2 hours 4 hours 8 hours
RMS device usage 2 hours 4 hours 8 hours
RMS enabled application usage 2 hours 4 hours 8 hours
Private Preview Reports
All User Sign-in activity 2 hours 4 hours 8 hours

Microsoft 365 Unified audit log latency

Yet another category for which the latency data was removed involves the set of audit log events ingested into the Unified audit log. Microsoft kept a table with latency values until April 2022, when it was replaced by the following text:

Microsoft doesn’t guarantee a specific time after an event occurs for the corresponding audit record to be returned in the results of an audit log search. For core services (such as Exchange, SharePoint, OneDrive, and Teams), audit record availability is typically 60 to 90 minutes after an event occurs. For other services, audit record availability may be longer. However, some issues that are unavoidable (such as a server outage) may occur outside of the audit service that delays the availability of audit records. For this reason, Microsoft doesn’t commit to a specific time.

Here’s how the original text/table looked like:

It can take up to 30 minutes or up to 24 hours after an event occurs for the corresponding audit log record to be returned in the results of an audit log search. The following table shows the time it takes for the different services in Microsoft 365.

Microsoft 365 service or feature 30 minutes 24 hours
Defender for Microsoft 365 and Threat Intelligence Check mark.
Azure Active Directory (user login events) Check mark.
Azure Active Directory (admin events) Check mark.
Data Loss Prevention Check mark.
Dynamics 365 CRM Check mark.
eDiscovery Check mark.
Exchange Online Check mark.
Microsoft Power Automate Check mark.
Microsoft Stream Check mark.
Microsoft Teams Check mark.
Power Apps Check mark.
Power BI Check mark.
compliance portal Check mark.
Sensitivity labels Check mark.
SharePoint Online and OneDrive for Business Check mark.
Workplace Analytics Check mark.
Yammer Check mark.
Microsoft Forms Check mark.

Remember, those reflect the Unified audit log ingestion latency, not the latency for the underlying workloads. I.e. the 24h latency for Azure AD sign-in events certainly does not represent the actual latency we observe on Azure AD side of things.

Microsoft 365 usage reports latency

I seem to vaguely recall the existence of a document that listed some data on Microsoft 365 usage reports latency as well, but I wasn’t able to locate it. In terms of the current documentation, best you can get is this statement from the Microsoft 365 Usage analytics article:

The back-end Microsoft 365 service will refresh data on a daily basis and provides data that is between 5-8 days latent from the current date.

If I ever manage to dig out the older documents, I’ll update this article.

 

Before closing the article, a warning. Take the above data with a grain of salt, they represent the supported/expected values at the time the information was originally posted, and as you all well know, things change fast in the cloud. And of course, none of the values listed above will help you, as they are not officially endorsed by Microsoft (anymore).

1 thought on “Microsoft 365/Azure AD audit logs and reports latency data

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.