Microsoft 365 had two separate faults on 12 October, one hitting Azure Rights Management across apps like SharePoint, Purview and Power BI, the other locking admins out of the Exchange admin center. Both ran for over five hours and both were Microsoft's own infrastructure, not anything in your setup.
Started
07:00 UTC
Duration
Lasted 5h 23m
Source
IsDown
Next time
Microsoft 365 is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Exchange Online, Microsoft 365 apps
What happened?
Microsoft's record for 12 October lists two incidents, both starting within an hour and a quarter of each other. The first began at 07:00 UTC and affected Azure Rights Management, meaning some users could not encrypt, decrypt or open protected files and emails across Microsoft 365 services that rely on it, including Purview, Power BI, SharePoint Online uploads and downloads, and parts of Microsoft 365 Copilot Chat. Microsoft said the ARM processing components were in an unhealthy state, restarted them, then redirected traffic away from the affected infrastructure. By 10:42 UTC they reported recovery across all affected regions, for a total duration of 5h 23m. The second incident started at 08:15 UTC and blocked admins from the Exchange admin center entirely, returning an "Internal Server Error" on every access attempt. Microsoft's engineers traced this to unexpected HTTP 302 redirects and eventually to a recent EAC configuration change. They tested a rollback starting around 11:21 UTC, completed it by 13:04 UTC, and told affected admins to close their existing EAC browser session and start a new one to pick up the fix. That incident ran 5h 24m in total. No user reports were filed during this window on our side, and components_affected lists only Microsoft 365 apps and Exchange Online, which lines up with the two write-ups rather than a broader collapse. Microsoft published ten update entries across the two incidents, each with its own scope and next-update time, which is a reasonable amount of detail for faults that ran this long.
Learning
Neither incident here would show up on a simple uptime check of your own product, because the failures sat inside Microsoft's rights management processing and inside the EAC's own configuration, layers you do not control and cannot probe directly. If your product depends on ARM for encrypting or opening protected files, your app could look perfectly healthy by every internal metric while users still hit decrypt failures, because the break was on Microsoft's side of the handshake, not yours. The EAC incident is a clean example of a provider-side configuration rollback: Microsoft identified a recent change as a likely contributor, rolled it back over roughly two hours, and only then saw error rates drop, something no amount of watching your own endpoints would have surfaced. History here isn't unusual for Microsoft 365: 49 incidents in the last 90 days with a median duration of 7 hours 15 minutes, and these two incidents, at 5h 23m and 5h 24m, ran shorter than that median but still long enough to matter. Our own 30-day figures show 21 incidents with a median duration of 5h 13m, close to what played out on this day. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
