We've been tracking 62 major AWS, Azure, Google Cloud, and Cloudflare outages since 2020 that have a public write-up. Each one has the provider's own root cause, the region, and how long it lasted.
Once you line them up, a few patterns jump out, and most of them aren't what people expect. Here's the cheat sheet.
The 30-second version
- The median major outage lasted 6 hours and 8 minutes. Not a blip. A full workday.
- 55% were caused by a change or a bug. Config pushes and deployments (32%) and software bugs or automation (23%). Fires and floods are the minority.
- Power and cooling failures are rarer but brutal. 18% of outages, with a median of about 21 hours.
- 37 of the 57 outages with a known end ran longer than 4 hours. 16 ran longer than 12.
- Only 7 were fixed within an hour. Plan for "hours," not "minutes."
- 2025 and 2026 had the most incidents we recorded (16 and 18). Partly more outages, partly more detailed public write-ups.
What actually takes the cloud down
| Cause | Share of outages | Median duration |
|---|---|---|
| Configuration or deployment change | 32% | 5h 21m |
| Software bug or automation | 23% | 5h 35m |
| Power or cooling | 18% | ~21h |
| Network | 6% | 3h 17m |
| Capacity or overload | 6% | 9h 22m |
| Physical damage (fire, water, drones) | 5% | 27h to months (2 still ongoing) |
| Other or not stated | 5% | n/a |
| DNS | 5% | 1h 35m |
Two things stand out. Most outages start with the provider's own changes or code, and the physical ones (power, cooling, fire) are rare but last the longest, because you can't roll back a flooded room.
Five lessons, and what to do about each
1. "Multi-AZ" won't save you from a regional outage
Plenty of these outages took out a whole region, or a regional control plane that every zone depends on. In Paris, a cooling-water leak flooded a UPS room and started a fire, and shutting down that one building took the region's control plane offline for over a day. When an outage is regional, spreading across zones doesn't help, and the median outage in this data lasted about six hours.
Do this: run critical services in at least two regions, and know which managed services you use are regional (they often are, even when compute is zonal).
2. The scariest outages start with a routine change
Paused gateway OS updates resuming all at once. A cache optimization that reordered DNS records. A release that withdrew about 1,100 customer IP prefixes. None of these were exotic. They were routine changes.
Do this: roll out your own changes the way you wish your provider did: one location at a time, gated on health metrics, with automatic rollback. Your config changes count too, not only code.
3. DNS breaks fast and heals slow
DNS outages had the shortest median (about an hour and a half), but the effects can outlast the fix: resolver caching keeps bad answers alive, and downstream systems take time to catch up. One CloudFront DNS incident caused 1h 35m of errors, while CloudFront configuration propagation stayed delayed for up to 7h 48m.
Do this: know your TTLs, keep them low on records you might need to fail over, and don't assume a fixed DNS problem is fixed for your users.
4. Backups that live in the same region aren't backups
In March 2026, drone strikes in the UAE and near a facility in Bahrain damaged AWS infrastructure. AWS later said some data held only in the affected UAE zones, and data held only in the Bahrain region, cannot be restored. The teams that recovered had copies somewhere else.
Do this: copy backups to another region (or another provider) and actually test a restore from there.
5. Your recovery plan has a human bottleneck
With a median outage of six hours, the question isn't whether you'll get paged. It's whether your system shifts traffic by itself or waits for someone to wake up, read the status page, and run a runbook for the first time.
Do this: automate the failover path and rehearse it. A failover you've never tested is a guess.
The cheat sheet
| If this fails... | ...this is what saves you |
|---|---|
| One availability zone | Running in 3 zones with load balancer health checks |
| A whole region | Active capacity in a second region and health-checked traffic routing |
| The provider's control plane | Workloads that keep serving without new API calls (no scaling or deploys needed to survive) |
| DNS | Low TTLs, a failover plan, and patience with resolver caches |
| A bad config push | Gradual rollouts with automatic rollback |
| Your only copy of data | Cross-region backups with tested restores |
| Power or cooling at a facility | Not being in only one facility |
How the data was built
Most entries come from the provider's official status page or post-incident report; a handful of older or thinly documented incidents rely on press coverage. Every source is linked in the full tracker. It only includes major outages with a public write-up, so smaller incidents are missing, and recent years look busier partly because providers now publish more detail. Durations are the provider's own numbers where they give them.
The full tracker, with every incident, cause, and source link, is here: Cloud Outage Tracker. It's updated every week.
If you want the math on why one bad hour wrecks a 99.99% SLA, I wrote that up separately: Four nines is 4 minutes and 19 seconds. Nobody on your team can respond that fast.
Disclosure: I work at Control Plane, where we build a platform for running apps active-active across regions and clouds. The data above comes from the providers' own reports, plus press coverage for a few older incidents.
What's the worst outage you've lived through, and what would have saved you? Curious what people's real failover setups look like.
