Microsoft has given a preliminary root cause for its 12-13 November Microsoft 365 outage. Its final service health entry for incident MO1550821, posted at 04:17 UTC on 14 November, says “this incident was caused by a failure in the systems responsible for establishing secure connections to the service”, and that “traffic shifts during standard network maintenance and upgrades exposed a latent bug”. The text is republished by the University of Pennsylvania’s PennO365 incident page and Cloud Admin Hub.
Microsoft’s record dates the impact from 16:20 UTC on 12 November to 16:10 UTC on 13 November: 23 hours 50 minutes, by our arithmetic. Its public posts ran longer. From the first @MSFT365Status post at 17:54 UTC on 12 November to the post at 06:09 UTC on 14 November saying it had “restored service to the remaining impacted customers and regions” is 36 hours 15 minutes, by our arithmetic. The full Post-Incident Report is not out yet.
Business Pill · Concentration Explained
A short explainer on concentration: what happens when many users depend on one provider. It teaches the general idea only and says nothing about this outage.
The key insight: As we read Microsoft’s final entry, the failure sat in a shared front door rather than in any one app: once the systems that set up secure connections stalled, 20 services that reach Exchange Online lost access together. Microsoft’s record counts 23 hours 50 minutes of impact, against 36 hours 15 minutes of public posts, by our arithmetic.
The final entry describes a chain. The latent bug left systems “unable to complete new connection requests, causing a rapidly increasing number of requests to queue for processing”. Then, Microsoft wrote, “the affected servers exhausted their available processing capacity and could no longer accept new connections, resulting in widespread service access failures”.
It names the trigger in one line: “The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change”. It also says: “This was a technical issue not related to cyber or AI / agents”. Microsoft calls the cause preliminary: “While our analysis of the underlying root cause is ongoing”.
On the slow recovery, the entry says: “Given the scale of demand, we restored services gradually, validating stability at each stage. While this took longer, it helped ensure a stable restoration”.
Microsoft’s own updates on the Microsoft 365 outage, from its first post at 17:54 UTC on 12 November to the preliminary root cause at 04:17 UTC on 14 November and the restoration post at 06:09 UTC. Entries as republished by PennO365 and Cloud Admin Hub; elapsed hours are our arithmetic.
How the Diagnosis Changed Over 37 Updates
The PennO365 extract lists 37 timestamped updates on MO1550821, by our count. At 17:54 UTC on 12 November, Microsoft posted on X that it was investigating mailbox access issues “in the Americas”. At 18:27 UTC it saw “elevated load across multiple regions”.
By 19:30 UTC it had “paused all deployments and configuration changes” and said the load was driven “by a large number of servers being unexpectedly unavailable”, not by more traffic. At 22:03 UTC it reported that “a core process on the affected servers is becoming overwhelmed”. At 00:00 UTC on 13 November, restored servers “can become unresponsive again once they begin receiving traffic”.
The cause came into focus at 01:12 UTC: “a process on the affected servers responsible for establishing secure connections becomes overwhelmed”. In the same update Microsoft began “reverting a recent network configuration change that correlates with the start of impact”. At 07:24 UTC it reported “positive results for server stability” after a patch to an “upstream authentication/routing configuration component”.
At 09:03 UTC it extended the email timeout window to 48 hours to protect delayed mail. At 17:57 UTC it apologised and first named the network capacity upgrade. The preliminary root cause followed at 04:17 UTC on 14 November, and the restoration post at 06:09 UTC.
Who Was Hit, and the Phishing That Followed
The final entry lists 20 services, by our count, from Exchange Online and Microsoft Teams to Copilot, Intune, Purview and Windows 365. It says features “that interact with Exchange Online and email services were impacted”, while elements that do not depend on Exchange Online “remained functional”.
The BBC reported that Downdetector “had 140,000 people from 74 countries report issues with Outlook on Thursday evening”, a self-reported count, and that more than 430 million people use Microsoft 365 apps, citing Microsoft’s website. Our outage piece and first report track the spread.
Microsoft Threat Intelligence posted on X on 14 November that it “observed an active phishing campaign exploiting the Microsoft 365 service disruption on November 12”. The emails “reference the legitimate Exchange Online incident EX1550543”, and Microsoft said the activity is “consistent with credential phishing, although credential collection and malware delivery have not been confirmed”.
Hours from Microsoft’s first post at 17:54 UTC on 12 November to its preliminary root cause and restoration post, against the impact window in its own record; the Bloomberg time is as reported in our 14 November piece. All durations are our arithmetic.
What Microsoft Has Promised
The final entry says: “We’ll provide a preliminary Post-Incident Report within two business days and a final Post-Incident Report within five business days”. Counting from Friday 13 November US time, that points to Tuesday 17 November and Friday 20 November, by our count; Microsoft gave no dates.
Earlier updates said the report would come “with root cause and defense-in-depth actions after mitigation is complete”. A Microsoft spokesperson told CNBC: “We are deeply sorry for the disruption this incident has caused our customers and partners”.
The Structural Read
As we read the 37 updates, Microsoft’s diagnosis moved from load to mechanism: at 18:27 UTC it saw elevated load, at 19:30 UTC it said servers were unavailable rather than traffic rising, and at 01:12 UTC it named the secure-connection process.
As we read the record, the gap between the recorded 16:10 UTC end time and the 06:09 UTC restoration post is the part the record does not explain; the final entry itself says restoration of remaining customers and regions was still under way when it was posted.
Microsoft 365 Service Health, MO1550821 final entry, 14 November 2026
“Given the scale of demand, we restored services gradually, validating stability at each stage.”
Three Implications
FOR IT ADMINSMicrosoft promises a preliminary Post-Incident Report within two business days and a final one within five business days of its final entry.
FOR SECURITY TEAMSMicrosoft Threat Intelligence says phishing emails reference the real incident EX1550543; it tells organisations to confirm disruptions in the Microsoft 365 admin center.
FOR BUYERS OF COPILOT AND TEAMS Features that interact with Exchange Online were impacted across 20 listed services, the final entry says, while elements that do not depend on it remained functional.
The framework says: “The product is the interconnection.”
As we read it, this outage shows the cost side of that design: one connection layer failed and the services wired into Exchange Online failed with it. The framework is the owner’s argument and does not discuss this incident.
What Is Not Established
As of our read at about 10:10 UTC on 15 November, the PennO365 extract showed the record’s root-cause field as N/A, and we found no published Post-Incident Report document. Microsoft has not named which network capacity upgrade or which network change was involved, or how many tenants and users were affected. The updates we read do not mention service credits.
Two details in the record do not line up. Its header start field reads 10:05 UTC on 12 November, while the entry text says 16:20 UTC. And the final entry, posted after the recorded 16:10 UTC end time, still says Microsoft continues “to restore service to remaining customers and regions”; the restoration post came 13 hours 59 minutes after that end time, by our arithmetic. We read Microsoft’s entries through these two republications, not in an admin center.
This Week In The AI Supercycle
AI Lost Its Central Banker, the Lab Oligopoly, and the Future of Open Source
This week’s issue: the Nvidia leadership change, read as the AI build-out losing its central banker: who now finances the GPU landlords, backstops the data centres and sponsors open models, and why two labs are becoming the bank.
Microsoft’s preliminary root cause is a latent bug in the systems that set up secure connections, exposed by traffic shifts during network maintenance and upgrades. Its record counts 23 hours 50 minutes of impact; its public posts spanned 36 hours 15 minutes, by our arithmetic. The preliminary Post-Incident Report is due within two business days of its final entry.
95,000+ executives read Business Engineer for the AI strategy frameworks cited by ChatGPT, Claude, and Perplexity.
A note on sourcing. We read Microsoft’s service health entries for incidents MO1550821 and EX1550543 as republished verbatim by the University of Pennsylvania’s PennO365 incident page, which extracts them from its Microsoft 365 admin console, and checked the final entry against a second republication on Cloud Admin Hub. We also read the Microsoft 365 Status and Microsoft Threat Intelligence posts on X, the BBC’s and CNBC’s reports, and our own earlier coverage.
Durations, update and service counts are our arithmetic. As of our read on 15 November, Microsoft had not published its Post-Incident Report. We did not contact Microsoft.
Gennaro Cuofano is a CRO and tech executive who has worked in AI since late 2015, starting with bringing NLP, natural-language generation, voice and chatbot products to the marketing industry. His background is in law and finance: he holds a Master's degree in Law and an International MBA with an emphasis on corporate finance (LUISS Business School and the University of San Diego, 2012), and worked as a financial analyst at a real-estate investment firm in San Diego and as an assistant controller. His work focuses on business model strategy, business engineering and, more broadly, structural analysis: how companies make money, read from their own filings. He created FourWeekMBA and leads research there and at The Business Engineer, his newsletter on AI and business strategy, with over 95,000 subscribers and more than 1,000 published analyses. His writing has also appeared on Entrepreneur (for example, How to Digitize a Family Business in Europe) and HackerNoon. Find him on LinkedIn and Substack. See how we source.
