azure
Root cause
This outage started with the weather. On September 4, 2018, a severe thunderstorm moved over the area near Microsoft's South Central US datacenter outside San Antonio, Texas. Lightning and the associated electrical activity drove high-energy voltage swells into the facility. Those swells damaged cooling and electrical infrastructure, and once cooling was compromised, temperatures inside the datacenter began to climb.
Modern datacenter hardware is designed to protect itself. As the ambient temperature rose past safe thresholds, storage and compute equipment began shutting itself down rather than risk permanent damage or data corruption. That self-protection is the correct behavior, but at scale it meant a large slice of the South Central US region powered off, more or less at once. Starting around 08:42 UTC, a broad set of resources in the region went offline.
Recovery was slow by design. Bringing a datacenter back after a thermal event is not a simple power-on. Engineers had to restore cooling safely, power hardware back up in controlled stages, and carefully validate the integrity of storage that had shut down under abnormal conditions. Microsoft chose to prioritize data integrity over raw speed, which is why the region was not declared substantially healthy until roughly 21:30 UTC the following day, more than a full day of impact.
Business impact
For anyone building on the cloud, this incident is a durable case study because it broke two comfortable assumptions at once.
A single physical facility can take out a "region," and one region can ripple globally. The most surprising part of September 2018 was not that South Central US went down; it was that some global services degraded worldwide. Parts of Azure Active Directory, the Azure portal, and other platform services had supporting infrastructure or dependencies rooted in the affected region. When it fell, those hidden dependencies surfaced. That pattern, a supposedly global service tripping over a single-region root, recurred in later events like the January 2023 global WAN outage. It is a reminder to ask what your "global" providers themselves depend on.
Single-region deployments had no safety net. Customers who ran storage and compute only in South Central US, whether for data-residency, latency, or cost reasons, had nowhere to fail over. Their workloads were down for as long as the region was, which was more than a day for many. The teams that fared best had genuine cross-region redundancy and could shift read or write traffic elsewhere.
Recovery time, not just failure, is the risk. Because Microsoft deliberately recovered slowly to protect data, the outage was long. Business-continuity plans that budget for a short blip underestimated this class of event badly. A physical-infrastructure failure has a fundamentally different recovery profile than a software rollback like the May 2019 Azure DNS incident.
Prevention and lessons
You cannot stop a thunderstorm over Texas. You can decide how much of your business is willing to share a datacenter's fate.
- Treat single-region as a conscious risk decision, not a default. If a workload lives only in South Central US (or any single region), write down why, and write down the recovery-time consequence. For anything business-critical, plan real cross-region or paired-region redundancy. Our region pairs and availability zones guide walks through the tradeoffs.
- Audit hidden dependencies on any one region. This event proved that even "global" services can have a regional root. Map where your identity, DNS, secrets, and CI/CD pipelines actually live. A workload spread across three regions is still fragile if its deployment pipeline runs from one.
- Plan for long recovery, not just fast failover. A thermal or electrical event can take a datacenter offline for a day or more, and providers rightly recover slowly to protect data. Your RTO assumptions and your customer communications should account for a multi-hour to multi-day worst case, not a five-minute blip. Build that scenario into your business-continuity plan.
- Verify your backups and their restore path live somewhere else entirely. A backup stored in the same region as the primary is not a backup during a regional outage. Confirm that backups replicate to a different region and, critically, that you have rehearsed restoring from them.
If your workloads were pinned to South Central US, an outage of this length almost certainly breached your monthly SLA. Quantify the downtime with the Azure SLA credit calculator, then package the claim using the Azure credit-claim playbook. To catch regional degradation the moment it starts, and to see the hidden global ripples faster than a status page will admit them, Next Signal monitors Azure at the service level continuously.