Microsoft 365 Outage Restored, 13–14 November 2026

What to know

• Official incident IDs: EX1550543 (Exchange Online) and MO1550821 (wider Microsoft 365).
• This report covers official updates from the 11:11 UTC freeze on 13 November through restoration. The earlier official record, including the first acknowledgement at 17:54 UTC on 12 November, is in Part 1: the outage, 12–13 Nov.
• At 06:09:51 UTC on 14 November, @MSFT365Status said it had “restored service to the remaining impacted customers and regions.” A post-incident report has been promised but has not been published.
• Microsoft’s official cause wording, apology, and recovery steps are in the Latest update card above, including that this was “a technical issue not related to cyber or AI / agents.”
• At a 14 November check after the restoration post, the public status page no longer showed a Microsoft 365 degradation banner; consumer products were marked Operational, and Azure still showed no issues. This is not an Azure outage.

Confirmed: what Microsoft has said

The public official record is @MSFT365Status on X, status.cloud.microsoft, and Microsoft Learn’s Service Health guide. Admin-center incident text is tenant-authenticated. The official history through 11:11 UTC on 13 November is in Part 1.

Official updates continued after that freeze. The 16:40 UTC @Microsoft statement — the cause, the apology, the gradual restore, and the promised post-incident report — is quoted in the Latest update card above. The complete official thread from 11:11 UTC through restoration is in the table below.

The first official public restoration notice, at 06:09:51 UTC on 14 November, said: “We have completed our efforts to address the underlying issue of the incident and restored service to the remaining impacted customers and regions. Further updates can be found at MO1550821 in the Microsoft 365 admin center.”

The official UTC timeline

No official @MSFT365Status post was found after the 06:09:51 UTC restoration notice, including at a 14 November re-check after that post. Microsoft has not stated an official estimated start time on X; the first official acknowledgement, at 17:54 UTC on 12 November, is in Part 1. Third-party start clocks are not official.

Which services were affected

The fuller service discussion, including the partner reprint of MO1550821, is in Part 1. During the incident, official public wording covered Exchange Online mailbox access and broader Microsoft 365 connectivity under MO1550821, delayed mail acknowledged by the 48-hour timeout, and Azure, where the public page said no Azure issues at the time of the check. At a 14 November check after the restoration post, the public degradation banner was gone, consumer products were marked Operational, and Azure still showed no issues.

Do not flatten this into “Teams is down” or “OneDrive and SharePoint are down.” Exchange-dependent features were hit; core Teams messaging and meetings, and files stored directly in SharePoint Online, were described as largely still working.

What is known about the cause — and what is not

There is still no published official PIR and no official final root-cause report. Microsoft Learn defines “Post-incident report published” as a Service Health status that appears after a PIR is issued; that status has not been seen for this event. The official public cause wording is in the 16:40 UTC @Microsoft statement quoted in the Latest update card, including that this was “not related to cyber or AI / agents.”

Charles Lamanna, an executive vice president, wrote at 22:02:21 UTC on 13 November: “This was not a cyberattack or an issue caused by AI tooling.” He also wrote: “Our investigation points to technical challenges and failure modes (cascading failures + thundering herds at our network perimeter) that made recovery more difficult than normal,” and: “We will publish the post-mortem shortly covering the step-by-step timeline and our many repair items to avoid similar outages in the future.” That is his attribution, not a published PIR.

Earlier official status updates, through the 11:11 UTC freeze, are operational findings in Part 1, not a final PIR.

Speculation — do not treat as fact

A confirmed cyberattack, or “no cyberattack, case closed”; a named bug or a completed configuration rollback as the cause; that “Azure VNet config changes” is Microsoft’s official cause; that a third-party tenant status-page timestamp is the official resolution time; that failover to other network gateways, an authentication or routing configuration patch, or traffic throttling have been confirmed in official public Status posts; that the PIR or post-mortem has been published; an official global user count, or phrases such as “millions of users” unless clearly quoting a named outlet; that Azure, or “all of Microsoft,” is down; or that Teams, OneDrive, or SharePoint are wholly unavailable.

Reported: scale and impact

Earlier user-report totals and press start clocks are in Part 1. They are not official Microsoft figures.

On Saturday 14 November, Reuters, via Investing.com, quoted the official 06:09 UTC post and said services had “fully recovered across Teams, Outlook and its other products.” That is Reuters’ wording, not the official restoration quote. It also said the outage “prompted airlines to warn customers of communication lags” and mentioned delays at trading firms. The same Reuters piece, and LiveMint, reported statements from IndiGo, Air India, and Akasa about email and support-channel delays; Air India also said, in LiveMint, that flight operations were unaffected. These are reported impacts, not official Microsoft figures.

In a 13 November update, Tom Warren of The Verge wrote that, according to his sources, the outage is linked to Azure VNet config changes. Microsoft has not said “Azure VNet.” Official wording is the network-capacity-upgrade sentence in the Latest update card.

What to do

These are standing practices from Microsoft documentation, applied to this incident — not a live walkthrough, and not a fix for a current error.

Check official status before you rebuild a profile or “fix” a client. Microsoft Learn tells administrators to check Service Health first: sign in at admin.microsoft.com, then open Health > Service health (or the Service health card on Home). If you cannot sign in, use status.cloud.microsoft and follow @MSFT365Status. Use the incident IDs, here EX1550543 and MO1550821. A restoration notice has been posted, and a post-incident report has not. Service Health and @MSFT365Status remain the live check.

For Outlook, Microsoft recommends Cached Exchange Mode so a local copy of a Microsoft 365 mailbox remains available when the network is slow or unavailable. It is the default in classic Outlook, is not available in new Outlook for Windows, and cannot be used with POP/IMAP. Official work-offline steps are in How to work offline in Outlook for Windows.

Wait for the official PIR before treating the root cause as closed, and re-check Service Health and @MSFT365Status before closing an internal incident or before this report is published.

What’s next

The post-incident report is promised, not published. @Microsoft said it “will provide a full post-incident report once our review is complete.” Lamanna said Microsoft “will publish the post-mortem shortly.” Further updates were pointed to MO1550821. No official, incident-specific SLA credit guidance was found; this report does not invent a claim deadline. Re-check @MSFT365Status and status.cloud.microsoft before this draft is published, in case a PIR or a later Status post appears.

Sources

• @MSFT365Status, 13 Nov 11:11 UTC to 14 Nov 06:09:51 UTC, including the 11:11 UTC update and the 06:09:51 UTC restoration notice. The earlier official thread is in Part 1.
• @Microsoft official statement, 16:40:18 UTC, 13 Nov, also posted by @MSFT365Status at 18:05:19 UTC
• Charles Lamanna, 22:02:21 UTC, 13 Nov
• status.cloud.microsoft (including a 14 Nov check after the restoration post) · How to check Microsoft 365 service health
• Reuters via Investing.com (14 Nov update); LiveMint (airline statements, reported); The Verge (13 Nov update)
• Microsoft Support: Cached Exchange Mode · Work offline in Outlook for Windows

Part 1: the outage, 12–13 Nov

Special report · 14 November 2026 · updated 14 November 2026, 06:09 UTC