Resolved. Microsoft stopped updating MO1472904 on the evening of September 16, after roughly four and a half hours. The last entries said impact reports had subsided and telemetry was stable — and, notably, that Microsoft had not found a matching fault inside the Microsoft 365 service itself. As of September 18 there is still no published root cause. Admins can watch MO1472904 under Service health in the Microsoft 365 admin center for a post-incident report.
Around 9:20 in the morning Eastern time on Wednesday, September 16 (2:20 in the afternoon in the UK), Microsoft 365 stopped letting some people in. Outlook on the web, the Microsoft 365 admin center, the Azure portal and other services answered sign-in attempts with a bare 502 Bad Gateway or 503 Service Unavailable page. Microsoft opened incident MO1472904 with the title “Some users in the United States and United Kingdom may be unable to access Microsoft 365 services”.
The odd part, and the useful part, was who it hit. People who were already signed in mostly carried on working. People who had to prove who they were, because they opened a new browser, their session expired, they got a multi-factor prompt, or they set up a new device, got the error page. The mail servers were fine. The front door was not.
What people saw
- Outlook on the web: a 502 or 503 error instead of the sign-in page, or a sign-in that spun and then failed.
- Outlook on the desktop and phones: usually fine at first, because the app already held a valid token. It broke when that token needed renewing: a password prompt that never accepted the password, or “Need password” in the status bar.
- Admin center and Azure portal: the same 5xx errors, which meant many admins could not open the very page that explains the outage.
- Teams and the rest of the suite: hit or miss, depending on whether the app needed a fresh token during the window.
What Microsoft said
Microsoft’s first public note, on the Microsoft 365 Status account: “We’re investigating an issue with users being unable to access some Microsoft 365 services. Further details are provided under MO1472904 in the admin center.” The admin center entry said users in the United States and United Kingdom “may encounter 502 or 503 errors when attempting to access Microsoft 365 services”, and that engineers were focused on “the cause of the Single Sign-On (SSO) failures and associated 5xx errors” while reviewing “upstream dependencies” that might be contributing.
About an hour in, Microsoft reported that some customers were seeing service return and that the issue was “no longer occurring” for them, while the investigation continued.
How it was resolved
This is the part worth reading carefully, because it is not the usual ending. Microsoft never announced a fix. There was no rollback, no failover, no “we have applied a mitigation and are monitoring recovery”. The incident simply stopped hurting and the updates stopped.
By late afternoon UTC on September 16, roughly four and a half hours after the first reports, the admin center entry read that “impact reports have largely subsided, and service telemetry continues to indicate stable service conditions”. The same update added the line that changes the story: the investigation had not identified a corresponding issue within the Microsoft 365 service environment, and engineers were “assessing whether conditions outside the core service path contributed to the reported impact”.
In plain English: Microsoft looked at its own sign-in service, found it healthy, and started looking at the network in front of it. That points at the edge — gateways, load balancers, a peering or routing problem on the path between users in the US and UK and the authentication endpoints — rather than at Entra ID falling over. It also explains why the outage was geographic rather than global, and why it cleared without a deployment.
What Microsoft has not said, two days on, is which condition that was, whose network it was on, or what stops it happening again. No post-incident report has been published for MO1472904, and until one is, the honest summary is: the front door jammed for four and a half hours, it unjammed on its own, and the official explanation is still outstanding. Be sceptical of any writeup that tells you the precise cause — Microsoft has not given one.
What was really failing
Every Microsoft 365 sign-in goes through the same single sign-on service, Microsoft Entra ID, and its gateways. A 502 or 503 from that layer means the request reached Microsoft’s edge but nothing behind it answered. Nothing was wrong with your mailbox, your files or your password. Token issuing was the thing that broke, so anyone who needed a new token was turned away, and anyone holding a good one sailed through. Given what Microsoft said afterwards — healthy service, suspect path — the break was most likely in front of the token service rather than in it, but the effect on your users is identical either way.
That is why the damage was so uneven inside a single office. Two people at the next desks, one working normally and one locked out, is the signature of an authentication outage, not a mail outage.
The next time the front door sticks
- Do not sign out. Do not reboot. Do not “try a fresh browser”. During a sign-in outage a working session is the most valuable thing you own. Signing out throws it away and puts you at the back of the queue. Tell users the same.
- Do not reset passwords. A 502 or 503 is a server saying it cannot answer. It is not a wrong password, and a reset during an authentication outage may not even take.
- Check the status page, then the incident number. The Microsoft 365 status page works without a Microsoft 365 sign-in. If the admin center is down for you too, the @MSFT365Status feed carries the MO number.
- Keep a second way in. An admin account that is still signed in on another machine, or a break-glass account with its own sign-in path, is what lets you read the incident when the portal itself is throwing 503s.
- Afterwards, expect a wave of prompts. As the service recovers, tokens that failed to renew during the window get renewed all at once. A burst of MFA prompts an hour after recovery is normal, not a second incident.
Getting “Something went wrong” from Office on an ordinary day, with no incident on the status page? That is a fault on the PC, not at Microsoft. The fix is in the knowledge base: Office 365 sign-in: “Oops, something went wrong”.
Were you caught in this one? Did your users notice, or did their cached sessions carry them through? Tell us in The Patch Panel. If a post-incident report lands in your admin center under MO1472904, we would like to see it — we will update this post when Microsoft publishes a root cause.
