Microsoft 365 Outage: What Broke Overnight

Microsoft 365’s Friday started badly for Singapore teams. Outlook mailboxes, Teams, SharePoint, OneDrive and Copilot were among the services that failed or slowed for users here and in other regions, with the first Singapore outage reports arriving around 7am.

The disruption began during the North American afternoon, which put the start at about 2:26am Singapore time on Friday, Nov 13. Microsoft has not reported a cyberattack. Its public updates describe an infrastructure and configuration problem that removed a large number of servers from service and overloaded the ones still running.

What happened

Microsoft’s advisory, tracked as EX1550543 and MO1550821, began with reports that users could not connect to Exchange Online mailboxes in the Americas. Microsoft soon widened the warning: the issue could affect Microsoft 365 connectivity in any region.

Microsoft’s advisory named Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR. Outlook, which depends on Exchange Online, was the most visible impact. User reports collected by Downdetector also covered Word, Excel, PowerPoint and OneDrive; The Guardian described that wider set. OpenAI and Anthropic also reported problems with their Microsoft 365 connectors, which link ChatGPT and Claude to Microsoft services.

Downdetector, which relies on user reports rather than Microsoft’s telemetry, recorded nearly 130,000 Outlook reports near the peak. In Singapore, CNA reported 250 Outlook reports at 7.05am and 535 at about 7.55am. About 40% of those reports involved the Outlook app, 25% involved receiving messages, and others involved login problems.

Those numbers measure complaints, not total affected users. They are still useful as a timing signal: the incident was visible in Singapore before many offices opened, and it was not limited to one company or one network.

Microsoft also dealt with a separate Teams incident earlier on Thursday, tracked as TM1550488. That one ran from 9.45am to 10.53am ET and affected Teams messaging. Microsoft says it has fully resolved that event. It is a different incident from the Exchange Online and Microsoft 365 outage, and the two should not be merged into one cause without evidence.

What Microsoft says went wrong

Microsoft’s first explanation was higher load across multiple regions. That was incomplete. The company later said the load was not caused by a traffic surge. A large number of servers had become unexpectedly unavailable, shifting their work onto the remaining infrastructure.

The failure was tied to server health checks. Microsoft said some servers were failing automated checks and dropping out of service. It paused all deployments and configuration changes, moved traffic away from the affected systems, and began restarting servers.

The restart was not a clean fix. Microsoft found that a core process responsible for establishing secure connections was becoming overwhelmed, causing a loss of capacity. Some servers that returned to service became unresponsive again once they received traffic. Microsoft isolated part of the infrastructure, restarted it, and redirected traffic to test recovery before applying the approach more widely. It later validated an alternative service health check method.

Microsoft also identified recent configuration updates as a potential cause and was assessing whether reverting a small number of them would speed recovery. That is narrower than a confirmed root cause. The company has not published a final explanation, and the incident remains a reminder that automated health checks can remove capacity faster than operators can restore it.

Why the recovery was gradual

Cloud services are designed to route around failed servers, but that only works while there is spare capacity. When enough servers leave the pool at once, the remaining machines take more connections, run hotter, and fail their own checks. The result is a cascading problem rather than a single broken component.

That is why Microsoft’s recovery updates moved from “restarting affected servers” to “validating an alternative health check method” to “returning a portion of servers and observing limited recovery.” Each step had to be tested before it was applied broadly. Returning too much traffic too quickly risked knocking the restored servers offline again.

As of 9.30am Singapore time, Microsoft had not declared the incident fully resolved. Its latest public guidance pointed to gradual recovery as applications reconnect, with the next detailed update expected around 10am Singapore time. Teams that need a definite all-clear should check the Microsoft 365 admin center for the two incident IDs rather than relying on social media summaries.

What Singapore teams should do now

• Do not resend queued mail. Email providers such as SparkPost are still retrying messages to Outlook.com, Hotmail, Live, MSN and Microsoft 365 recipients. Resending creates duplicates once Microsoft accepts the original message.
• Check the admin center, not just Downdetector. Downdetector shows user complaints; Microsoft’s advisory shows the affected services and recovery status. Search for EX1550543 and MO1550821.
• Use an alternate channel for time-sensitive work. If email or Teams is the only path to a client or an approval, you do not have a fallback. A phone number, a second provider, or a documented out-of-band contact is the actual contingency.
• Expect AI connectors to fail with the suite. ChatGPT and Claude connectors that depend on Microsoft 365 inherit the outage. Do not treat a connector error as a separate AI incident until the Microsoft service is healthy.
• Review change controls after recovery. Ask for the root-cause report, the configuration changes involved, and how the health checks were tested. The useful question is not whether Microsoft had a runbook; it is whether the runbook could restore capacity without removing more servers.

What to watch

The next milestone is a full-resolution notice for EX1550543 and MO1550821, followed by a root-cause report. Watch whether Microsoft confirms the configuration updates as the cause, whether the failed health checks were triggered by a specific component, and whether the recovery process changes.

For buyers, the practical lesson is that a single-vendor productivity suite is a concentration risk even when the vendor is reliable. The outage did not require a sophisticated attack. It required enough servers to become unavailable at the same time, and a recovery process that had to be re-engineered while customers were waiting.

Sources

CNA: Singapore users affected in global Microsoft outage
The Guardian: Microsoft begins restoring services
CNBC: Widespread Microsoft outage takes down Outlook and other 365 services
BleepingComputer: Massive Microsoft 365 outage
SparkPost status: Microsoft outage delivery delays
Microsoft 365 service health