Microsoft Outages by the Numbers: 79 Azure Incidents Since 2021

As of 13 November 2026, the Microsoft 365 outage that began on 12 November was still open and its cause was unconfirmed. BleepingComputer, citing Microsoft's advisory MO1550821, reported a 1:26 pm ET start. The advisory listed Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR.

CNBC reported at around 2:30 am ET on 13 November that users might still be unable to connect, with no timeline for a fix. That is more than 13 hours from the start, longer than 54 of the 79 Azure incidents below. The comparison is loose: this is a Microsoft 365 incident, not an Azure one, and the clock runs between two news reports rather than two times Microsoft stated in a review.

Microsoft's explanation shifted during the day. BleepingComputer reported that its stated cause moved from elevated load to servers becoming unexpectedly unavailable, and that it was investigating whether reverting a small number of recent configuration updates could speed recovery. CNBC reported that Microsoft was not aware of any malicious activity. Microsoft has not confirmed a configuration change as the cause, so this post draws no conclusion about what started the outage.

Microsoft 365 is not in the dataset: reviews of its incidents go to customers' admin centres, not the public Azure status history. What the Azure record offers instead is the pattern of how long outages last and what starts them.

Azure's status history publishes a review for each qualifying incident and keeps it for five years. FactsFigs read all 81 reviews, from 9 November 2021 to 30 September 2026, on 13 November 2026, and parsed the stated impact window from each of the 79 that remain after the two removals.

One break matters. From 1 June 2022 Microsoft publishes reviews only for broad issues, where before it published them for all publicly communicated issues. Of the 79 incidents, 17 were published before that date and 62 after, so year-on-year counts are not like for like and this post does not compare them.

Each cause is the trigger Microsoft states, coded by FactsFigs into seven groups with the stated wording kept as evidence.

The median incident ran 8.6 hours, but the mean is 15.1 because the long ones are very long: 26 of the 79 lasted 12 hours or more and five passed 48.

The five longest: Australia East's 2023 power and cooling failure at 105.5 hours; a Microsoft Graph error in November 2021 at 87.0, traced to a change; an Azure SQL Database and Cosmos DB defect in February 2022 at 72.0; a Software Load Balancer change across multiple regions in June 2022 at 70.6; and a January 2025 East US 2 networking failure at 50.2, also after a change.

A window is not the whole experience. For Australia East, Microsoft says the vast majority of services recovered within 12.2 hours, yet the window runs to full mitigation on 3 September 2023.

Of the 79 incidents, 44 (55.7%) began with something Microsoft did: a configuration change, a code deployment, an automated key or certificate rotation or a maintenance tool. Those 44 account for 611 of the 1,192 impact hours, 51.3%, with a median of 7.8 hours.

The reviews are specific. In December 2025 an automated key rotation broke Azure Resource Manager, which handles management operations, in Azure China and hours later in Azure Government. Microsoft's review says "an inadvertent automated key rotation resulted in ARM failures to fetch authorization policies." The windows ran 9.17 hours in China and 3.15 in Government.

Housekeeping can do damage too. In November 2024, per Microsoft, "the decommissioning process inadvertently deleted the Traffic Manager profiles under the subscription," leaving storage accounts unreachable in several regions for 11.7 hours. In July 2024 an Azure OpenAI change "took effect soon after it was committed," and "all resources in those resource groups were deleted in a short span of time." That one ran 23.6 hours.

All four Azure OpenAI incidents in the set began with a change. The May 2026 review of a 7.4-hour one describes the trigger as "a change in an upstream API layer used by a Microsoft first-party workload, Microsoft 365."

The result does not come from the 2022 scope change: a change is the most common trigger on both sides of it, 8 of 17 incidents before 1 June 2022 and 36 of 62 after.

Only 10 of the 79 incidents trace to power or cooling, 12.7% of the total. Yet their median is 21.3 hours, about 2.7 times the 7.8-hour median for changes, and they account for 265 of the 1,192 impact hours, 22.2%. Six of the ten ran longer than 20 hours. All ten were published after the June 2022 scope change.

The record is Australia East, 105.5 hours from 30 August to 3 September 2023. Microsoft's review says "a utility voltage sag was caused by a lightning strike on electrical infrastructure approximately 18 miles from the impacted Availability Zone." The chillers then failed to restart and storage and SQL recovery were slow, though most services were back by 22:40 UTC on 30 August, 12.2 hours in.

It is not a one-off. A severe thunderstorm sent cooling systems in West US 2 into lockout for 22.1 hours in May 2026. A utility voltage dip in Southeast Asia in February 2023 ran 32.2 hours, and a grid voltage sag caused a 9.5-hour thermal event in West Europe in November 2025.

The trigger is brief and the recovery is not: cooling that would not restart, generator transfers that failed and storage slow to boot recur in these reviews. Power is also the limit on data centre growth, covered in our explainer on AI data centre electricity.

Load or capacity: 8 incidents, median 7.6 hours, longest 29.2. In July 2022 the wide area network saw "upwards of 60 Tbps in additional traffic," a 5.3-hour incident. Two of the eight involved attacks: Microsoft said it believed three spikes against Azure Front Door in September 2022 were "malicious HTTPS flood attacks," and the June 2023 portal errors were Layer 7 DDoS attacks.

Fibre or network hardware: 7 incidents, median 8.0 hours, longest 24.45, after subsea cable cuts that Microsoft attributes to a seismic event, affecting South Africa North and West in March 2024. A drilling operation struck fibre used by Microsoft in East US in March 2025, and one faulty London-area router in June 2022 had only four of its 140 physical ports failing, which alerting missed.

Software defects: 6 incidents, median 5.5 hours, including the third-longest of all, the 72.0-hour SQL and Cosmos DB failure caused by a race condition in a Remote Procedure Call mechanism. The line with changes is the stated trigger: when a review names a deployment or configuration change as what set it off, it counts as a change even if a latent bug did the damage.

Third party: one incident, in August 2022, a Canonical Ubuntu security update that disrupted virtual machines and Azure Kubernetes Service for 34.0 hours. Three further reviews, median 3.5 hours, do not state a trigger.

The Azure record gives a plain answer to why Microsoft goes down: most often, Microsoft. Of the 79 incidents, 44 began with a change it made and only one traces to a third party. Power failures are the other half of the story: rare, but slow to recover from.

Four limits apply. Windows are often for a subset of customers or one region, so a 2-hour incident can reach more people than a 40-hour one. Microsoft writes its own reviews. The cause groups are FactsFigs' coding of the trigger it states, and of 81 codings 7 were low confidence, none among the 44 changes, which are all high (40) or medium (4). And because Microsoft changed what it publishes on 1 June 2022, the counts cannot show whether Azure is getting better or worse.

Like any list built from what its owner reports, the record counts only what Microsoft publishes. Our post on the fastest supercomputer meets the same limit, where a ranking can only place the machines entered.

The 12 November outage may close with a final duration and root cause, and either would change how it compares with these figures. All figures stand as of 13 November 2026.