azureRoot cause
At around 21:56 UTC on July 18, 2024, a configuration change was applied to a set of Azure Storage scale units in the Central US region. The change included an incomplete allowlist - the mechanism that determines which callers a storage scale unit will accept traffic from. With legitimate sources missing from the list, the affected scale units began rejecting the very traffic they existed to serve, and storage availability across an availability zone dropped.
What turned a storage misconfiguration into a region-scale event is Azure's dependency chain. Virtual Machines do not hold their disks locally - OS and data disks live on Azure Storage. When storage rejects requests, VMs don't degrade; they fail. And when VMs fail, everything above them fails: application workloads, databases running on IaaS, platform services with compute in the zone, and - most visibly - Microsoft 365 services with dependencies in Central US. Users saw Teams, and other M365 experiences degrade while the root cause sat two layers below anything they could see.
The recovery asymmetry is worth noting. Backing out the configuration change and restoring storage took a few hours. Restoring compute state took the rest of the night: tens of thousands of VMs had to re-establish disk connectivity, some required manual remediation, and dependent services each had their own recovery tail. Storage was the root cause; VM recovery was the long pole.
Business impact
For enterprises, this outage was a business-continuity case study in three ways.
First, the blast radius crossed the IaaS/SaaS boundary. Organizations that had carefully planned Azure DR discovered that their productivity suite was coupled to the same regional storage they were insulating their workloads against. A BIA that lists "Microsoft 365" as an independent vendor misses this coupling - the BC/DR planning hub treats M365 dependency coupling as a first-class planning gap for exactly this reason.
Second, it was a single-zone storage failure with multi-zone consequences. Workloads that were genuinely zone-redundant - zone-redundant storage, VMs spread across zones behind a load balancer - rode through with degraded capacity rather than an outage. Workloads that were merely deployed in Central US, on locally-redundant storage in the wrong zone, went down. The difference between those two postures is configuration, not cost, and it is the central argument of our zones and region pairs guide.
Third, the calendar was brutal. The unrelated CrowdStrike Falcon incident began the next day, blue-screening Windows fleets worldwide. Enterprise incident teams spent that week running two major-incident processes simultaneously - a reminder that your continuity plan must assume concurrent crises, not one tidy incident at a time. Teams with a single on-call rotation and a single war-room process found both saturated.
Prevention and lessons
The uncomfortable lesson is that a customer could have done everything "right" inside a single zone and still gone down. The realistic mitigations:
- Make zone redundancy the default, not the upgrade. Zone-redundant storage and multi-zone VM deployments turned this event from an outage into a capacity blip. Audit which of your Central US-style single-region workloads are actually zone-redundant - the answer is usually "fewer than the architecture diagram claims."
- Test the storage-failure mode specifically. Most game days simulate VM loss. This event was disk loss: VMs alive but unable to read or write. Inject that failure in staging and watch what your applications, health checks, and auto-recovery actually do. The BC/DR hub's five-step process includes this as a named scenario.
- Map your Microsoft 365 coupling. If your incident bridge, documentation, and communication channels all live in Teams and SharePoint, a regional Azure event can take out your response tooling along with your workloads. Keep one communication channel and one runbook copy outside the Microsoft dependency tree.
- File the claim. Fourteen hours is well past SLA thresholds for affected resources. Azure credits are claimed, not granted - track the incident's tracking ID, gather your resource health evidence, and submit within the claim window. Watch the Storage status page rather than social media for the authoritative timeline.