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:
|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|
|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|
|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.
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).