Cloud outage analysis ยท 27 October 2026
Two cloud outages in three weeks: where does your backup live?
On 20 October 2026, Google Cloud's London region went offline for almost eight hours. Three weeks earlier, a network failure on Microsoft Azure hit 18 regions for about six hours. As far as public reports show, neither was a data-loss story. Both are a recovery story: could your business have kept working, and where was your backup while all this happened?
Key takeaways
- What: two multi-hour outages at two of the biggest cloud providers, a whole Google Cloud region in London and Azure gateway services across 18 regions.
- Different failures: Google lost a region. Azure lost the gateways that connect offices and data centres to Azure. Each breaks a different part of a recovery plan.
- The real risk: a backup only helps if you can reach it when your main systems cannot. A copy in the same region and account fails with everything else.
- The fix: one immutable, tested copy outside the primary region and account, a second way to reach your systems, and a written plan for the first hour.
- Not a reason to leave the cloud. It is a reason to know where your data and your backups actually live.
What actually happened
These were not cyberattacks, and the public reports we reviewed do not describe lost data. They describe something that hurts a business almost as much: systems that stayed unreachable for hours.
Google Cloud, London, 20 October
According to Cisco ThousandEyes, the europe-west2 region showed a "complete drop in availability" from about 06:10 UTC. Google attributed the problem to power-related issues on its status page. Services began to recover around 11:30 UTC and Google declared the incident resolved around 14:00 UTC.
Microsoft Azure, 30 September to 1 October
From about 20:30 UTC, gateway services failed in 18 regions at once. ExpressRoute and VPN gateways, the connections many businesses use to link their offices and servers to Azure, were hit first. Azure Firewall management, Application Gateway and Azure VMware Solution were also reported as affected. Microsoft said the timing correlated with infrastructure operating system servicing activity and paused that work. At the time of writing, the failure mechanism had not been confirmed.
| Incident | What failed | Length | Stated cause |
|---|---|---|---|
| Google Cloud, 20 Oct 2026 | The whole europe-west2 (London) region became unavailable | About 7 h 50 min | Power-related issues, per Google's status page as reported by ThousandEyes |
| Azure, 30 Sep to 1 Oct 2026 | ExpressRoute and VPN gateways, plus other network services, in 18 regions | About 6 hours | Not confirmed. Timing correlated with infrastructure OS servicing, which Microsoft paused |
Why a few hours is a big deal
Cloud providers publish uptime targets, and when they miss them the usual remedy is a service credit. A credit does not bring back a day of sales or a missed payroll run. What matters to your business is how long it can operate without the affected systems, which is your recovery time objective (RTO). Our guide to RTO and RPO explains how to set one.
Put an example four-hour target next to these two outages and both run past it.
Two outages, two different layers
The incidents did not break the same thing, and that is the point. Your cloud setup has layers, and a failure in any of them can take you offline.
- A regional outage (Google, London) takes out everything that lives in the region. Running in several availability zones protects you from one data centre failing, but not from the whole region going down.
- A gateway outage (Azure) may leave your servers running but cut your office, your staff or your backup software off from them. Your data is fine. You just cannot get to it.
- A compromised admin account needs no outage at all. An attacker with stolen credentials can delete backups that sit in the same account as the systems they protect.
Where your backup lives decides what survives
The same backup job, stored in different places, gives very different results when something fails. This table shows how three common setups hold up against the three risks above.
Only the last row survives all three. That does not mean every business needs the most expensive setup. It means you should know which row you are in, because most small businesses discover the answer during the outage.
What to do this week
None of this needs a new platform. It needs five answers and one afternoon.
| Ask yourself | A good answer looks like |
|---|---|
| Where does each system, and each backup of it, live (region and account)? | Written down, with at least one copy outside the primary region and account |
| If our VPN or dedicated cloud link is down, how do staff reach systems? | A second path, or a documented offline procedure |
| How long can each system be down? | An agreed RTO per system, not one number for everything |
| When did we last restore from the offsite copy? | Within the last quarter, timed. See our restore test checklist |
| Who decides to fail over, and who tells customers? | Named people, with phone numbers that do not depend on the cloud |
Step 1: Map your systems and backups
List every business system and the region and account it runs in. Next to each, write where its backup is stored. Most businesses find at least one backup sitting beside the system it protects.
Step 2: Keep one immutable copy somewhere else
Store at least one backup copy in a separate region, and ideally a separate account or provider, with immutability turned on (object lock or similar), so that neither a regional outage nor a stolen admin login can remove it.
Step 3: Give yourself a second way in
If your only route to the cloud is one VPN or one dedicated link, the Azure incident shows what happens when it fails. Keep a second route or a documented break-glass procedure, and test it.
Step 4: Set service-health alerts
Subscribe to your provider's service-health notifications (Azure Service Health, Google Cloud Service Health) so you hear about an incident from the provider before you hear about it from your staff.
Step 5: Write the first-hour plan
One page, agreed in advance. It should say who confirms the outage, what the business does in the meantime, and the point at which you restore from the offsite copy instead of waiting.
The bigger lessons
Outages are normal, so plan for them
Even the largest providers have multi-hour failures, and these two happened in the same autumn. The question is not whether it will happen to a provider you use, but whether it costs you an inconvenience or a bad week.
Hybrid links are a single point of failure
Many setups depend on one VPN or ExpressRoute connection for staff access, backup traffic and monitoring at once. Treat that link as a critical system and give it a fallback.
Backup location is a design decision
"It is backed up" is not an answer. "It is backed up in another region and account, immutable, and we restored from it in September" is.
Recovery is a plan, not a product
Our guide to backup versus recovery makes the same point: copies protect your data, and a rehearsed plan protects your business.
Frequently asked questions
What happened in the Google Cloud outage on 20 October 2026?
According to Cisco ThousandEyes, Google Cloud's europe-west2 (London) region showed a complete drop in availability from about 06:10 UTC. Google attributed it to power-related issues. Services began recovering around 11:30 UTC and Google declared the incident resolved around 14:00 UTC, about 7 hours 50 minutes after it began.
What happened in the Azure outage on 30 September 2026?
From about 20:30 UTC on 30 September, Azure gateway services (ExpressRoute and VPN gateways, with Azure Firewall management, Application Gateway and Azure VMware Solution also affected) failed across 18 regions, for about six hours. Microsoft said the timing correlated with infrastructure operating system servicing activity, which it paused. At the time of writing the failure mechanism was not confirmed.
Was any customer data lost in these outages?
None of the public reports we reviewed describe data loss. They describe loss of availability: systems and connections that could not be reached for hours. That is still a serious problem for a business that needs those systems to operate.
Does running in more than one availability zone protect me?
It protects you from one data centre failing, which is a common problem. It does not help if a whole region becomes unavailable, as London did on 20 October, or if the gateway that connects your office to the cloud fails, as in the Azure incident. Those need a copy and a plan outside the affected region and link.
Is a cloud backup enough?
Only if it is stored somewhere that does not fail together with your main systems. A backup in the same region and account as your workload can be unreachable during a regional outage and can be deleted by an attacker with stolen admin access. Keep at least one immutable copy in a separate region, account or provider.
What is an immutable backup?
A backup that cannot be changed or deleted for a set retention period, even by an administrator. It is usually built with object lock or WORM storage. It protects against ransomware and mistakes, but not against an outage by itself, which is why location matters as well.
Do small businesses need a multi-cloud setup?
Usually not. Running everything live in two clouds is complex and expensive. What most small businesses need is simpler: one tested, immutable copy of their data outside the primary region and account, a documented way to work during an outage, and a recovery time they have agreed in advance.
Not sure where your backups live?
We help small and mid-size businesses in Ontario, across Canada and in the United States answer three questions fast: Where are our backups? Are they safe from the same failure as our systems? And can we restore in the time we need?
- Recovery readiness review: a structured look at your systems, backups and recovery objectives.
- Backup location and immutability review: we map where each copy lives and what could take it out.
- Restore testing: we prove backups by restoring them, not by reading a green tick.
Sources
- Cisco ThousandEyes: Google Cloud outage analysis, October 20, 2026
- IsDown: Azure ExpressRoute gateway incident in multiple regions (copy of Microsoft status updates)
- Archyde: Microsoft Azure outage disrupts ExpressRoute and VPN gateways
- Google Cloud Service Health (official incident reports)
- Azure status history (official post-incident reviews)
This article reflects public information as of 27 October 2026. Microsoft had not published a full post-incident review for the Azure incident in the sources we reviewed, and Google's detailed incident report for 20 October may add facts. We will update this article when they do.