Microsoft 365 Outage Exceeds 12 Hours as Recovery Fails

By Rebecca Stone

A Microsoft 365 (cloud productivity suite) disruption first detected at 5 a.m. on 13 November lasted more than 12 hours without full global restoration. Microsoft reported failures across several regions and said recovery attempts had not produced sustained service improvements.

Which enterprise services failed?

Microsoft confirmed degradation affecting Microsoft 365 Business or Enterprise services, while users across multiple regions encountered service interruptions and degraded performance in the 13 November incident. Six named products were affected.

• Outlook, the email client.
• Exchange Online, the hosted email and calendar service.
• Microsoft Teams, the collaboration platform.
• SharePoint Online, the cloud content-management service.
• Copilot, the AI assistant.
• Defender XDR, the extended detection and response platform.

Microsoft issued updates through Service Health Status, its incident-status service, and X, the social media platform. The product list covered email, collaboration, document access, AI assistance and security monitoring.

What did Microsoft identify?

Microsoft initially found elevated loads caused by a large number of servers becoming unexpectedly unavailable. Those failures shifted traffic onto the remaining infrastructure. The company continued investigating why the servers became unavailable.

Microsoft continued to investigate the underlying server failures while working to return unavailable infrastructure safely to service and review recent configuration changes for possible links.

Microsoft gave this update:

“We’ve validated an alternative health check method on a subset of affected infrastructure, which allowed the servers in that subset to successfully return to service, and we’re now applying this change more broadly. We’re also preparing an automated recovery process to continually detect and restart unresponsive servers, to help keep them in service while this change progresses.”

Microsoft also said:

“Additionally, our review of recent changes has identified a small number of configuration updates that we’re investigating as potential contributors to the issue.”

How did recovery unfold?

Microsoft first used health checks and automated recovery processes to identify affected servers, then paused deployments and configuration changes while attempting to restore platform stability. It restarted servers and investigated whether reverting to a previous configuration could help. Microsoft said none of these attempts had worked so far.

• 10:15 a.m. AEDT (Australian Eastern Daylight Time): Microsoft reported partial recovery. Traffic rerouting helped reduce pressure on affected infrastructure.
• 11:50 a.m. AEDT: Some servers brought back online had become unresponsive again, undermining recovery. Microsoft began testing a rebuild using a previous configuration.
• 3 p.m. AEDT: Microsoft said its recovery changes were not working as expected. It pursued alternative recovery workstreams and continued analyzing traffic routing across its infrastructure.

Microsoft also worked to improve server stability and traffic flow. It adjusted traffic protocols, redistributed traffic and used strategic traffic-blocking measures.

Why did restoration remain incomplete?\n

Microsoft adjusted traffic protocols, redistributed traffic and used strategic traffic-blocking measures, then observed partial recovery in some regions without achieving a sustained return to normal service.

Microsoft acknowledged that the measures were not producing sustained recovery. At its latest update, the company said it was reviewing additional actions to improve overall infrastructure stability. It continued working toward restoring affected services.

The cited updates did not identify a final cause or announce full restoration after more than 12 hours. Some servers had become unresponsive again after Microsoft brought them back online.