Status as of September 17: Microsoft reports the issue is no longer occurring for affected users. A root cause has not been published yet. Admins can follow incident MO1472904 under Service health in the Microsoft 365 admin center for the post-incident report. If you still cannot sign in today, check the Microsoft 365 status page before you touch anything.
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. Public status trackers logged the incident as lasting roughly four and a half hours. Microsoft has not yet said what the upstream dependency was.
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 the service behind it could not answer. Nothing was wrong with your mailbox, your files or your password. The service that hands out tokens was struggling, so anyone who needed a new token was turned away, and anyone holding a good one sailed through.
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 General forum. We will update this post when Microsoft publishes the root cause.