The future of internet outages
The next outages start outside the building, last longer, and ship as tested automation. 2026 already showed the shape: regions that do not come back.

The next outage is less likely to be a server in your rack. It is a route, a feeder, or a region you cannot fail back into.
Per-site outage rates have been falling. Uptime Institute’s 2026 analysis is the fifth year of that result, and the year the improvement slowed. The public hyperscaler log had its busiest year at the same time. The incidents are in What broke in the 2026 cloud outages. The count behind the feeling is in Why major companies are seeing more outages in 2026.
Three properties already showed up in those write-ups. Some outages do not end. More of them start outside the data center. The software ones propagate faster than a status page can be typed.
Some outages will not get a green check
AWS’s Middle East regions are the template. Strikes in March damaged facilities in me-central-1 (UAE) and me-south-1 (Bahrain). AWS said two UAE sites were hit directly, a strike near Bahrain caused physical damage, and fire suppression added water on top of lost power. Months later, a public health update said resources hosted only in mec1-az2 cannot be restored. Control Plane’s 21 October log still has both regions open.
A bad deploy has a previous snapshot. A building that took a strike, a fire, and suppression water has disks you will not read again. Customers with a copy in another region resumed. Customers whose only copy lived in the damaged zone are still in the outage.
Uptime’s public-outage set already shows the duration shift. Incidents lasting more than 48 hours were a larger share for a second straight year, and in the 2025 compiled set they ran ahead of the 2020–2025 average. Fiber repairs, and anything else that needs a crew, are why.

Source: Annual Outage Analysis 2026, Uptime Institute. Figure 15.
A warm standby that has never served traffic will discover, during the outage, that the backup was a hope. Active-active, with the data you cannot lose already in a second location, is the design these incidents select for. Identity, DNS, secrets, and CI count. They are the dependencies teams find on the day the primary region is a construction site.
The failure starts outside the building
Uptime’s 2026 report says fiber and cable incidents led its 2025 public-outage set, at more than double their long-run average. The assets are subsea cables and terrestrial routes. The causes it lists are sabotage, accidental cuts, theft, and weather. A redundant path that shares a trench is a drawing.
22 June was a small version. Cloudflare investigated a fiber cut in eastern North America and warned of latency toward Europe, while user reports piled up across X, Reddit, Teams, Zoom, and Discord. Some of those brands had their own bugs the same day. Customers experienced one outage. The causes were several, joined by a shared route.
Power is moving the same way. Google’s July write-up starts with a 3 millisecond sag and ends 14 hours 55 minutes later at 44°C. Azure West US 2 in May was a 22 hour cooling lockout after lightning. AWS us-east-1 was heat and automatic shutdowns. Uptime’s note on AI halls is that many are new, and the density leaves less room for exactly this transient. A training run that already stops for a dead GPU will stop for the building.
The forecast is more incidents whose first symptom sits outside your provider’s code, and whose repair clock belongs to a utility or a fiber crew. A second region helps when it does not share the feeder, the conduit, or the conflict.
Generated code will ship the happy path faster
In Uptime’s 2026 resiliency survey, firmware and software faults were the top named cause of major IT-system outages, just ahead of configuration changes, among operators who could pick up to three causes. The report says the risk is moving from a misclick toward defects in software behavior and in how components interact. Then it says AI may reduce those errors, and AI may introduce them. More automation, the Institute’s release adds, can cause a different class of problem.
2026 already ran that class, and the write-ups are in the companion post: an empty filter that deleted about 1,100 prefixes, a safety check that approved every optical device because it looked at them one at a time, an internal client that retried a capacity error dozens of times, and a .de signer that failed names which do not even use DNSSEC.
Generated code increases the supply of changes that look like those. The model writes the implementation and a test for the path it understood. The empty string, the full set, and the unbounded retry are the paths it left unnamed. Review time did not grow with the diff volume. Cloudflare’s change had fifteen days in the tree, enough calendar for a second reader and not enough process to require one.
The teams that stay up will treat control-plane automation as a production change with a ceiling: stop the job when prefixes withdraw too fast, keep a snapshot you can restore without the network you just cut, and send the empty parameter in a test on purpose. That list is Cloudflare’s own follow-up after February. It is also a review checklist.
What still holds
A few practices survive this year.
- Keep a second copy of data you cannot regenerate, in a region that does not share fate with the first. Provider durability did not hold for
mec1-az2. - Assume rollback needs the thing that broke. If recovery depends on the region’s egress, practice the path that does not.
- Put a ceiling on mass actions. One prefix is maintenance. A thousand is an incident, and the job should stop itself.
- Rate-limit your own clients the way you rate-limit customers. Internal traffic is how a retry storm becomes a region.
- Review the diff that automates a delete, a route change, or a retry. ThinkReview does that on the pull request, on GitHub, GitLab, Azure DevOps, and Bitbucket, and from the editor through ThinkReview MCP. The finding that matters is the one a postmortem would otherwise publish: this call returns every row when the filter is empty.
Uptime’s survey says a growing majority of operators who had an impactful outage believe better process or configuration would have prevented it. That lever still moves when the racks get hotter.
A status page is a lagging indicator
The next outage arrives as a small tested change, a cut you do not own, or a region that stays red. The status page confirms it after customers already know. The work that changes the outcome happens earlier: a second location you have actually failed into, a rollback that does not need the broken network, and a review of the job that thinks it is only cleaning up.
2026 was the year those three left the architecture slides. The companies that publish the clearest postmortems are already writing them that way. The rest of us can read them before we ship the same bug.
Newsletter
Want the next one?
Leave your email and I’ll send the post when it’s published. Models, agents, and the review work in between. No drip after that.
One email when we publish. Unsubscribe in a click.