At 3:40 a.m. Japan time on 7 October 2026, part of a Japanese cloud stopped. A ransomware attack hit four zones of IDC Frontier’s IDCF Cloud East Japan Region 1, and 495 companies and local governments lost their servers. The next day the provider told customers that data in those zones would be difficult to retrieve or restore, and that recovery would only be possible from backups the customers held themselves.
That is the latest entry in a long year. In 2026 cloud regions went down because of war, heat, lightning, a voltage dip lasting three thousandths of a second, an automated account flag and an attack on the layer underneath the servers. None of these were exotic software bugs. They were the ordinary physics and paperwork of running buildings full of computers.
Every one of those failures was survivable for a website. Very few of them are survivable for AI that runs a substation, a ground station or a defence system. This post sets out what happened, what it means, and the test every operator should run before AI touches operations.
What happened to the cloud in 2026?
2026 was the year cloud regions failed for physical and administrative reasons, not just software ones. The incident reports are public, and they read less like IT tickets and more like facilities reports.
As of 13 October 2026:
| Date (2026) | Provider and location | Cause, in the provider’s words or the source’s | How long |
|---|---|---|---|
| From 1 Mar | AWS, UAE (me-central-1) and Bahrain (me-south-1) | Drone strikes caused “structural damage, disrupted power delivery” and water damage from fire suppression | Months. On 15 Sep AWS said data held only in one UAE zone cannot be restored |
| 7 to 8 May | AWS, northern Virginia (us-east-1, one zone) | A thermal event in a single data centre caused a loss of power | About 21.5 hours until cooling was back to pre-event levels |
| 19 to 20 May | Railway, on Google Cloud | An automated, erroneous suspension of the production account | About 8 hours, across every region |
| 29 to 30 May | Microsoft Azure, West US 2 (two zones) | Lightning caused voltage sags and swells that tripped cooling into lockout | About 22 hours |
| 13 Jun to 1 Jul | Two frontier models, worldwide | Access suspended to comply with an export control directive | 18 days 19 hours |
| 15 Jul | Google Cloud, Netherlands (europe-west4-a) | A 3 millisecond utility voltage drop, a failed backup power unit and a chiller controller that dropped offline | 14 hours 55 minutes |
| From 7 Oct | IDC Frontier, Japan (East Japan Region 1, four zones) | Ransomware | Ongoing. Data restore only from customer-held backups |
Sources: AWS Health Dashboard for the Middle East regions, InfoQ on the September AWS update, AWS us-east-1 thermal event, Railway’s incident report, Microsoft’s post incident review, IncidentHub’s H1 2026 report, Google Cloud’s incident report and IDC Frontier’s third notice.
These are the headline events. IncidentHub counted 4,723 outages at 86 cloud providers in the first half of 2026 alone, out of 30,246 outages across 1,082 providers, based on public status pages (IncidentHub, July 2026). The big ones made the news. The small ones are why your status page has a history.
Why were 2026’s outages about buildings, not bugs?
A cloud region is a set of buildings, and in 2026 the buildings were the weak point. Read the root causes in the table again: power, cooling, structural damage, an account record, a hypervisor. Software was usually the victim, not the cause.
Three of the reports deserve a closer look, because they show how small the trigger can be.
Google Cloud, 15 July. A 3 millisecond voltage drop on the utility grid tripped the breakers on both power feeds. One backup power unit took the load. The other failed. One row of racks lost both feeds. At the same time the chiller controller dropped offline and could not restart the water pumps, and the redundant chiller was out of service because of construction work. The data hall reached 44°C and machines were shut down. Customers lost service for 14 hours 55 minutes (Google Cloud incident report).
Microsoft Azure, 29 May. A thunderstorm did not cut power. It made power unstable. Cooling components across several data centres detected the abnormal voltage and, by design, locked themselves out. Microsoft’s own review says the cooling protection logic “prioritizes equipment protection and data security over operational continuity, which resulted in a full lockout rather than staged or degraded operation” (Microsoft PIR).
AWS, 1 March onwards. AWS reported that two of its UAE facilities were directly struck by drones and that a strike near a Bahrain facility caused physical damage. On 15 September it said it could not restore resources and data held exclusively in one UAE zone, and that damage in Bahrain “exceeded what our regional and multi-AZ services are designed to withstand” (InfoQ). We covered the wider pattern of strikes on data centres in Data centres are now targets.
A 3 millisecond voltage dip cost one cloud zone 15 hours. A control room cannot wait that long.
What is AI continuity?
AI continuity is the ability of an AI system to keep producing correct, accountable output when its network, cloud provider or supplier fails. It is not the same as uptime, and it is not the same as disaster recovery.
Uptime measures whether a service answers. Disaster recovery measures how fast you can rebuild somewhere else. Continuity asks a harder question: during the failure, does the system at the site still do its job, and can you prove what it did?
AI continuity has three parts:
- It keeps running. The model and the decisions it supports keep working at the site when the link or the region is gone.
- It stays under command. The operator can still roll back a model, pause a workload or stop the system without reaching a remote control plane.
- It keeps the record. A durable record of what ran, which model version, on which input, with which result, survives the failure and can be read by the operator and the regulator afterwards.
Lose any one of the three and you do not have continuity. You have a system that worked until it mattered.
What is a blast radius, and how big is yours?
The blast radius of a failure is everything that stops working because of it. Engineers use the term to design systems where one broken part takes down as little as possible. The question for AI in critical systems is simple: does a power fault in a data hall on another continent sit inside your blast radius?
For most AI deployed today, the answer is yes. A model served from a cloud region shares that region’s failure domain. A failure domain is the set of things that fail together. If your inference, your model registry, your identity provider and your logs all live in one region, they all share that region’s weather, its power grid, its cooling plant, its local conflicts and its provider’s billing and compliance systems.
If your AI shares a failure domain with a cloud region, it shares that region’s war, weather and billing system.
Railway’s May incident shows how far a blast radius can reach. Its workloads on its own servers and on AWS were healthy. But its edge proxies got their routing tables from a control plane hosted on Google Cloud. When Google Cloud’s automated system suspended the account, the routing caches expired and, in Railway’s words, “all Railway workloads across all regions were rendered unreachable” (Railway incident report). The workloads were up. Nobody could reach them.
That is the pattern to look for. The thing that fails is rarely the thing doing the work. It is the thing the work quietly depends on.
Why does recovery take longer than the fault?
In 2026 the fault was usually over in minutes, and the recovery took hours. That gap is where critical systems get hurt.
- Azure, 29 May: cooling was restored about two hours after impact began. Customer impact lasted about 22 hours, because storage had to be validated in sequence over roughly 14 hours and telemetry needed another six hours to clear its backlog (Microsoft PIR).
- Railway, 19 May: account access was restored nine minutes after the root cause was found. Disks, compute and networking each needed separate recovery, and the incident took about eight hours to move to monitoring (Railway).
- Coinbase, 7 May: chillers in one AWS data hall failed. Coinbase says trading and most customer surfaces were unavailable or degraded for roughly eight hours, with full recovery taking another twelve, partly because a managed messaging service got stuck and the effect cascaded through its systems (Coinbase postmortem).
- IDC Frontier, 7 October: six days later, the provider is still guiding customers to rebuild in a separate environment from their own backups (IDC Frontier).
Recovery has its own dependencies. Restarting thousands of machines creates load. Queued work floods back in. Third parties rate limit you. IncidentHub calls this out directly: recovery can trigger secondary outages (IncidentHub).
Recovery time, not fault time, is the number that decides whether a critical system was safe.
Why is multi-region not enough for critical AI?
Multi-region protects a workload from losing a region. It does not protect a site from losing the link, and it does not protect anyone from failures that are shared everywhere. The standard advice after each 2026 incident was to spread across zones and regions. That advice is right for web services. It is incomplete for AI in critical systems, for four reasons.
- The site may be the thing that is cut off. A substation, a mine, a ship, a ground station or a forward base often has one link, or none. If the link drops, it does not matter how many regions the provider has. The AI is on the other side of the gap.
- Some failures are global by design. An account suspension, an identity outage or a model access decision reaches every region at once. In June, two frontier models were suspended for 18 days 19 hours to comply with an export control directive, and downstream platforms that offered them had to switch them off too (IncidentHub).
- Copies may not be allowed to leave. InfoQ notes that the practical test after the AWS Middle East losses is whether regulatory or contractual obligations even permit a copy to leave the jurisdiction (InfoQ). For defence, energy and government data, often they do not.
- The ability to change things fails first. During the UAE event AWS said it was “not possible to launch new instances in the region” even while existing instances in the remaining zone kept running (AWS Health Dashboard). Running is not the same as being in command.
None of this is an argument against the cloud. Cloud regions are some of the best engineered buildings on earth, and their providers publish more honest incident reports than most industries. It is an argument about placement. Each decision should live where it can still be made when the network, the building or the supplier is gone.
What should AI in critical systems depend on?
AI in critical systems should depend on as little as possible outside the site it serves. That is the whole principle. A smaller blast radius comes from four placement choices.
| Decision | Large blast radius | Small blast radius |
|---|---|---|
| Where the model runs | A remote region, reached over the network | At the site, close to the sensors and the people who act on the output |
| Who can change or stop it | A remote control plane and a provider account | The operator, locally, with the same authority when cut off |
| Where the record of what ran lives | Logs in the same region as the workload | A durable record at the site, synced upstream when the link returns |
| What happens when the link drops | Requests fail or queue | The site keeps working and catches up later |
The cloud stays useful in this picture. It is the place to train, to compare, to aggregate fleet-wide insight and to archive. What changes is that the cloud stops being in the hot path of decisions that cannot wait.
This is the same logic we applied to national policy in Location is not control: who holds the keys, who chooses the models, who keeps the record of what ran, and who can stop the system. Continuity is that test applied to a bad day.
How do you test a supplier for AI continuity?
Ask five questions, and accept only answers you can verify by cutting the link yourself. We call this the continuity test. Any operator can put it to any supplier, including us.
- What shares a failure domain with each decision? Ask for a dependency map of every component the AI needs to produce one output: model weights, inference, identity, licensing, configuration, logging and time. Anything that lives in one region or one account is inside your blast radius.
- If the link is cut for 72 hours, does the AI at the site keep producing correct output? Not “degrade gracefully”. Keep doing the job it was deployed to do, with the model version that was approved.
- Can you roll back, pause or stop it while cut off? If changing the system requires a remote control plane, the operator is not in command during the one window when command matters most.
- Does the record of what ran survive the loss of the provider? You should be able to show a regulator which model ran, on which input, with which result, for every hour of the outage, even if the provider never comes back.
- When did anyone last cut the link on purpose? Continuity that has not been tested is a hope. Break the network on a schedule and find your real dependency map before an outage finds it for you.
For grid operators and other critical infrastructure owners, these questions belong in procurement, not in the post-incident review. Our energy page sets out where AI is already being asked to support operations.
Where Sector88 fits
Sector88 is one system to deploy, run and govern AI at every site, connected or completely cut off. Models run at the site, under the operator’s command. It keeps serving when the network is gone or untrusted, and it keeps a durable record of what ran. Our forward-deployed engineers take it from first benchmark to hardened production on real workloads. We built it for the day the region goes dark.
The cloud has a blast radius. Critical AI should sit outside it.