Microsoft needed 97 minutes to say its email was down

Microsoft 365 failed worldwide on 12 November 2026, and Microsoft’s repairs kept failing into Friday. The cause is still unconfirmed, but five earlier incidents since mid-2025 began with Microsoft’s own maintenance, code or configuration. That pattern, not one root cause, is what customers should plan around and what the coming post-incident report will test.

Microsoft 365 broke at 16:17 UTC on Thursday 12 November 2026, which was 17:17 in Bratislava, and by Friday morning in Europe Microsoft’s repairs were still failing. Exchange Online mailboxes stopped opening first. Teams scheduling, Copilot and Defender followed, and Downdetector logged reports from 74 countries within about an hour. At midday GMT on Friday Microsoft had published no root cause. It had only begun reverting a recent network configuration change that it said correlates with the start of impact. This article argues that the cause matters less than the pattern: most of Microsoft’s large outages since mid-2025 began with a change Microsoft itself made, and each recovery was slowed by the same shape of failure, healthy servers pulled out and survivors overloaded.

A 97-minute silence and a day of failed fixes

The sequence is public because Microsoft posts it, and it is unflattering. Incident EX1550543 began at 16:17 UTC. Microsoft’s first post on X arrived at 17:54 UTC, 97 minutes later, and it named only the Americas. Thirteen minutes after that the company conceded that users in any region could be affected. A companion incident, MO1550821, opened at 18:26 UTC for every service that depends on Exchange.

Engineers paused deployments around 19:06 and brought some servers back by about 21:08 using a different health-check method. Those servers stopped responding again at midnight once traffic reached them. Restarts looked promising at 01:50, the change was not taking effect by around 03:00, and at 04:57 Microsoft was scaling up virtual machines, some of which sat stuck in a bad state. Early on Friday it described its results as “marginal success”.

Microsoft’s explanation moved as well. It first cited elevated load on infrastructure in several regions, then said a number of servers had become unexpectedly unavailable while traffic had not risen, and only overnight did it mention a network change that correlates with the start. Each revision was more specific than the last, which is normal during an incident, but it means every cause stated so far is provisional.

Mail failures reached governments, police forces and contact centres

The damage was not confined to inboxes. Government systems in Singapore and Japan were disrupted, as were communications at the Supreme Court of the Philippines, and Australia’s spy agency and federal police were among the organisations hit. Pravda’s reporting adds British police forces warning about online reporting, health services warning of delayed prescriptions and airlines losing e-mail support while flights continued. Czech users also reported problems on Downdetector.

One failure inside the wave had a different cause. Dynamics 365 Contact Center went down for just under eight hours under its own ticket, CR1550885, which Microsoft attributed to connectivity failures in the database behind it. Treat a single incident number with caution: customers saw one outage, while Microsoft tracked several.

Downdetector figures, including more than 130,000 Outlook reports at the US peak, count only people who bothered to report. Microsoft has not published the number of affected users.

Failed health checks turned lost servers into an overload

Microsoft’s own description is specific about the mechanism. A large number of servers became unavailable, and the remaining servers had to carry the traffic. Total traffic had not risen. The unavailable servers were failing automated health checks, and Microsoft tested a workaround that bypasses the component processing them. A process that sets up secure connections became overwhelmed, then the servers stopped handling requests.

The recovery trap follows from that. Restored servers receive the whole backlog at once and fail again. One analyst quoted by Al Jazeera compared it to a four-lane road reduced to two, where the resulting jam shuts the road entirely.

Microsoft’s own Azure post-incident review for 29 September shows the same loop in a different service. Azure OpenAI instances in Sweden Central failed a health check that depended on a database connection, restarted by design and shrank the healthy pool, which drove more retries onto the survivors. Microsoft fixed it by decoupling the check. That is an analogy, not evidence about 12 November, but it shows how a protective mechanism can become the amplifier.

Capacity alone does not cure this kind of failure. On 12 November some of the virtual machines Microsoft added got stuck in a bad state, which stopped its network change from syncing, so new capacity could arrive no faster than the broken state could be cleared.

Microsoft’s own changes sit behind most large incidents since 2025

Five incidents with published triggers fit one description. On 9 July 2025 a configuration change saturated infrastructure behind Outlook for more than 19 hours. In January 2026 Microsoft blamed heavy load combined with reduced capacity during maintenance for almost 10 hours of trouble across North America. On 23 July 2026 a bug in an automated maintenance-request system removed IP routes from more devices than intended and disrupted Azure and Microsoft 365 for about five hours.

The August outage began with a code update to certificate management. On 30 September resumed gateway updates and an earlier change overwhelmed an Azure networking control plane in 33 regions for nearly six hours. In each of the five the trigger was an internal action. In the August and September reviews the recovery itself also hit limits: services that needed restarts to reload certificates, and a control plane that could not scale out.

Microsoft’s stated triggers, July 2025 to November 2026

The first five rows record a trigger that Microsoft or its post-incident reports name. The sixth does not, so the table counts triggers and says nothing about how many changes Microsoft ships safely each week. Without that denominator it cannot show that Microsoft is getting worse, only where its large failures tend to start.

The August certificate outage shows how early accounts get rewritten

The August incident is the best warning against trusting a first explanation. Microsoft’s live updates blamed an issue within a core authentication configuration, while administrators found an error message naming an expired certificate and wondered whether Microsoft had forgotten a renewal. Coverage during the incident treated the certificate story as unconfirmed.

Microsoft’s post-incident report, dated 10 September, settled it. A code update to the automated certificate management system stopped it distributing a subset of new certificates, and a separate defect in expiry monitoring let some of them lapse without an alert. The report puts the affected share at about 5% of Exchange Online, on infrastructure in North America and Europe, and says Microsoft Entra was not affected. The 67-hour figure is therefore the length of the incident record, not 67 hours of darkness for every tenant. Expect the 12 November account to move in the same way.

Europe’s sovereignty push gains an argument, not yet a switch

Outages feed a policy argument already under way. Al Jazeera notes that Europe is pushing to run more of its own digital infrastructure, and one technology analyst it quotes expects this outage to add pressure on dependence on Microsoft. The same analyst describes Microsoft’s hold as “intensive inertia” and does not expect a near-term revenue effect, because customers are bound by licensing contracts.

A second analyst doubts that any European firm could offer a credible alternative to Microsoft’s office suite, and expects organisations to invest in resilience rather than replacement. That reading fits the evidence better. The sources I reviewed report no migration decision caused by an outage, only complaints and credit claims.

Two second-order effects deserve more attention. Integrations used by AI companies such as OpenAI and Anthropic were disrupted too, which suggests the Exchange dependency now runs through automated tools as well as people. And in August the security tool Defender XDR was itself degraded, which means monitoring can sit inside the failure it is meant to diagnose.

Cooling failures and unconfirmed causes limit the change-control thesis

Three things weaken the argument. First, the 12 November cause is open. Microsoft said overnight that it had found no matching change, then began reverting a network configuration change that lines up with the start, and it has not called that change the cause. A rollback is a sign, not a verdict.

Second, not every large incident starts with a change. On 5 November 2025 a thermal event in cooling systems took storage units offline in West Europe, a physical failure rather than a software change. Third, the table has no denominator, as noted above.

Two other claims need care. Microsoft’s language on attacks softened from no indication of malicious activity to not being aware of any, a shift The Register noticed. Analysts quoted by Al Jazeera still see a technical failure rather than an attack, and Australia’s home affairs minister said Microsoft compared it to a faulty update. One analyst also blamed an exodus of experienced engineers, but that is an opinion offered without data.

Three decisions for IT leads before the post-incident report

Claim the credit before 31 December 2026. Microsoft promises 99.9% monthly uptime per service, but it does not apply credits automatically, and the claim deadline is the end of the calendar month after the outage. Exchange downtime counts only when users cannot send or receive in Outlook on the web, measured in user-minutes, and a suite customer is credited only Exchange’s share of the price. Resellers file on the customer’s behalf and set earlier cutoffs. The credit is the sole contractual remedy. One guide places anyone locked out since Thursday afternoon in the 50% tier, which needs more than 7.2 hours of downtime in a 30-day month, while another warns that only Outlook-on-the-web failure counts. Check both before telling finance what to expect.

Keep your own timeline. Microsoft’s service-health records can start late or disagree with themselves, so log when your first user reported trouble, how many users were hit and what error they saw.

Rehearse the fallback. Teams chats and calls mostly worked while calendars failed, and desktop Outlook may still show downloaded mail. Mail is delayed rather than lost, because Microsoft extended the retry window to 48 hours. Tell users not to resend everything.

The post-incident report will confirm or break the change-control thesis

Microsoft promised a full post-incident report once the incident is mitigated. Its recent record suggests the wait is short: the August report appeared a week after resolution, and after the July incident Microsoft said final reports usually follow within 14 days. That points to late November.

My forecast, which is analysis and not fact, is that the report will name an internal change or automated process. If it describes a deployment without staged rollout, a missing rollback check or a health-check design that punishes survivors, the thesis stands and the remedy is process. Azure’s own review of the 30 September incident already promises staged resumption of paused updates by October 2026 and stronger ExpressRoute gateway health checks by March 2027. If the report instead names hardware, an external trigger or an attack, the pattern still describes five earlier incidents but explains none of this one.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Microsoft hit by global outages: What happened and why?
Supplied the 74-country scale, the ‘marginal success’ status, the Home Affairs minister’s comparison to a faulty update, the January 2026 outage and the sovereignty and resilience commentary.

Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams
Established Microsoft’s description of unavailable servers, failed health checks, unchanged overall traffic and the health-check bypass, plus the incident IDs EX1550543 and MO1550821.

Microsoft 365 Outage – Current Status and SLA Credits
Provided the UTC timeline of fixes and relapses, the reverted network change, the 31 December claim deadline and the advice that delayed mail is queued rather than lost.

Microsoft outage hits Outlook, Teams and Copilot, disrupting thousands
Gave the Downdetector peak above 130,000 Outlook reports and the caveat that such figures do not measure actual users.

Microsoft přiznává problémy s řešením výpadků, které postihly jeho služby
Confirmed Czech users reporting problems and Microsoft saying its efforts were not progressing as expected.

Microsoft Outage Cut Agents Off From the Contact Center
Documented the 97-minute gap before Microsoft’s first public post, the separate Contact Center incident CR1550885, Microsoft’s stated recovery times and the 48-hour retry window.

Microsoft’s massive M365 outage stretches past 12 hours as its fixes keep failing
Showed Microsoft’s wording on malicious activity changing between updates and listed its failed mitigation steps.

Globálny výpadok služieb Microsoftu: aktuálny stav
Reported effects on British police, health services, airlines and Asian government e-mail, and Microsoft’s extended mail retry window.

Microsoft blames massive Microsoft 365 outage on maintenance bug
Documented the 23 July 2026 outage, in which a maintenance-request bug removed IP routes, and its roughly five-hour timeline.

Microsoft’s 19-hour Outlook outage exposes fragility in cloud infrastructure
Established the July 2025 outage, its duration of more than 19 hours and Microsoft’s statement that a configuration change saturated infrastructure.

EX1464935: M365 Outage Due to Forgotten Certificate Renewal
Recorded the real-time error message naming an expired certificate during the August 2026 outage and Microsoft’s authentication-component statement.

Microsoft 365 outage, August 2026: what the SLA pays
Summarised Microsoft’s 10 September post-incident report on the August outage, including the certificate cause, the 5% Exchange Online scope and the lagging service-health records.

Microsoft 365 outage credits: what you can really claim
Explained how credits are calculated in user-minutes, the narrow Outlook-on-the-web definition of Exchange downtime, the suite proration and the reseller route.

Azure stumbles in Western Europe, Microsoft blames ‘thermal event’
Documented the 5 November 2025 West Europe cooling failure used as a counterexample to change-driven outages.

Azure status history
Provided Microsoft’s own post-incident reviews for 29 and 30 September 2026, including the health-check restart loop, the 33-region gateway failure and the staged-rollout commitments.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.