We are experiencing an issue with multiple services in
europe-west2 beginning on Monday, 2026-10-19 23:08 PDT.
Due to a power event we had suffered an outage within
europe-west2-b zone. The power event is mitigated. Partial
mitigation to infrastructure services will be observed within the
next 30 minutes and the remaining services will be mitigated there
after.
So some kind of power failure happened to bring down one zone. Unfortunate, but this kind of stuff happens. That is why all the cloud providers have multiple zones, and I'm amazed the big companies reported as down weren't using multiple zones.
(Also reporting the times in PDT is quite unhelpful for users of this zone who are likely based in the UK or EU)
GCP is kind of odd in that some hardware is only available in certain zones, and some hardware is technically available in multiple zones but the capacity is not evenly spread. I've had to implement infrastructure code for GCP that interrogated hardware availability by region and zone to place VMs, trading off multi-AZ availability where it made sense.
I'm not saying it's the case here, but sometimes the cloud providers themselves have inter-zone dependencies, or even inter-region dependencies that can cause outages in other zones and regions.
> I'm amazed the big companies reported as down weren't using multiple zones
Much as with backups - if you don't test them, they don't exist.
Everywhere I've worked has had multi-AZ infrastructure. I have never worked anywhere where the failure of an AZ has been simulated regularly, with second-order effects mapped out.
We set up our applications and services to be multi-AZ natively. It's not particularly difficult with how many AWS services are regional or global (Admittedly, I still expect a potential DNS failure to cause issues if and when that occurs). However we are just part of a workflow, we integrate with other applications that are not multi-AZ and would be impacted. That's just out of our hands.
It's like our on-prem systems were ordered to plan out and exercise DR plans to account for a data center going offline, but we can't exercise a DR plan fully if part of the plan is 'Adapt to how application X, which is hosted in the same datacenter, also chose to fail over.' We do not own application X. There is no appetite in the business to co-ordinate the DR exercise across the entire company at the same time.
We can't even do it all in a lower environment because there are dependencies on systems that are shared across environments. Some massive, redundant filesystem that is sync'd across our data centers, but the sync is a boolean. One datacenter instance of it is the primary and the others are read-only until they get promoted. We have one of these and lower environments are just a different root folder on the system with different access patterns, but they can't make DataCenter A the primary in prod and DataCenter B the primary in UAT.
Often there are irritating legal geographic limitations on where cloud hardware can exist for a given country. I can understand why, but there is this particular drawback of having all eggs baskets close together.
It's crazy. My main account is with Starling and I have a Lloyds account for a saving an account and some free cinema tickets. I don't think I've ever had an issue with Starling, it's great - Lloyds fails to sign in about 50% of the time consistently.
A lot of the information people are leveraging here comes from Downdetector which is mostly users reporting that stuff is down, not whether they are actually down. It's a really bad source.
It's a pretty good source ime (at least, massive spikes tend to correlate well with issues). Traditional organisations aren't as transparent as SF tech companies about service downtime. Plus, if the service isn't working for its users, I wouldn't say it's actually up.
For me it was Revolut. No access to my main account, no withdrawals, no card payments since the morning. App doesn't work, there's no phone number to call, nobody to talk to. Dark side of neobanking, I guess.
The stand-in system has a limited subset of features, i.e. no bells and whistles, but enough that you can get any actual banking done.
(Not an ad / I have no connection to Monzo, I just had some appreciation for a bank doing this properly as normally banking IT is a disaster. Plus the idea of keeping a separate codebase for almost an entire bank's functionality seems very invested.)
Starling also has a disaster recovery system across cloud providers, although it is implemented differently to Monzo's (I used to work there on multi-cloud).
Multi-cloud is really tough, tbh. It's easier said than done, especially if you care about data consistency at all.
I have built these system for financial institutions since before cloud providers. It is hard/impossible if not well constrained at a level that supports data availability and consistency well (ie using a proper database with the correct setup across all locations with the underlying OS configuration/patches applied uniformly - the latter lesson cost IBM a lot of money due to system downtime for a financial institution that I brought back online). Many software vendors offering on-prem versions don’t know how this works well exactly, so I’ve had to help them along the journey and get them to sign-off for their contractual obligations to be upheld in the setup.
I opened up a Revolut account a couple of years ago with the intention of switching my current account to it (i.e. wages going into it etc), but I got spooked after hearing that they weren't registered as a UK bank and thus subject to the various regulations and protections. I tried using Chase instead and have been happy with it so far.
I used to use Starling as my main and they were fine, until I started getting issues with random card declines due to "fraud prevention" and nobody to talk to. I switched to First Direct and like the peace of mind of having a human on the phone if needed (when I wanted to make a huge transfer for my house deposit it was nice to have!) and I still get perks like free foreign card transactions.
Yep, I probably won't bother switching to them now as Chase provides a good service as far as I know, though I do get a bit twitchy about its U.S. links. However, it's headquartered in the UK and is a division of J P Morgan Europe, so I hope that provides some level of distancing from the inevitable economic collapse of U.S. A.I. companies.
I think sovereignty might be the _cause_ of the banks' outages...
This is affecting companies that put everything into a single GCP region in the UK for their entire business - aka most likely British companies or government with a data sovereignty requirement.
The UK, at least, is big enough that you can have multiple regions within the same country. There's a lot of distance between Glasgow and London, for example. Maybe not enough if both are targeted with nuclear warheads, but at that point, we have bigger fish to fry I suspect.
Most European countries have enough space within the country to do that, and, for most things, except banking typically, hosting within the EU is enough, it doesn't have to be within your own country.
Microsoft Azure has two entirely seperate regions.
A "full function" one in/around London.
And a "tickbox" one for multi-region requirements near Cardiff.
The tickbox one has constant capacity constraints and a large number of Azure services aren't in it, but if you need to tick the "two regions and in country" requirement, you kinda/sorta can.
But considering what these sovereignty rules aim to achive, and as someone mentioned, that the problem may be due to companies relying on a single region provided by a hypersclaler due to data sovereignity rules.
Then redundancy has to be considered by both the company and the rulers.
The main selling points were auto-scaling and not having to self-host. Or, on a higher level, outsourcing accountability, being able to point at someone else if something goes wrong, as exemplified by the present case.
The whole thing has always been strange. The outsourcing of accountability for instance has always been a pain. Technically that is what you're doing, but if you work in IT operatings and GCP or AWS takes down your service, your boss still tell you to fix it.... but now you can't.
In terms of upfront costs, cloud is always cheaper, initially. There's sort of a weird sweet spot for cloud. If you're to small it makes no sense operationally, if you're to large, it just way to expensive.
It's a little worrying that banking with an institution from one of the world's financial capitals is so vulnerable. I would've thought London would've been priding itself on security, stability, safety, etc. Confidence in their systems is their bread and butter
Afaik, even Russia and Ukraine aren't having such issues while dealing with data centres getting droned, lol.
I think Azure’s design is fine. Some cool ideas that work, some “cool ideas” that are a pain in the ass. The implementation is complete dog shit. Barely anything works the way it’s supposed to, and when something works, better not touch it or you can’t touch it. Many times the answer is “why don’t you delete everything and try this other thing?”
The documentation is indeed worst than that still. It’s a maze of articles, none of them actually answer your questions because in Azure the answer to everything is “it depends”. Every doc page has to also be a sales pitch for something. They love inventing skus and features that are basically “now if you want this service to work, you must enable this feature. Otherwise, this is not supported. And to enable this feature, you must delete and recreate your instance” you know, just figure it out.
(Also reporting the times in PDT is quite unhelpful for users of this zone who are likely based in the UK or EU)
For example, AWS us-east-1 outages have caused global outages on multiple occasions, such as https://www.networkworld.com/article/4168878/aws-hit-by-us-e...
Much as with backups - if you don't test them, they don't exist.
Everywhere I've worked has had multi-AZ infrastructure. I have never worked anywhere where the failure of an AZ has been simulated regularly, with second-order effects mapped out.
It's like our on-prem systems were ordered to plan out and exercise DR plans to account for a data center going offline, but we can't exercise a DR plan fully if part of the plan is 'Adapt to how application X, which is hosted in the same datacenter, also chose to fail over.' We do not own application X. There is no appetite in the business to co-ordinate the DR exercise across the entire company at the same time.
We can't even do it all in a lower environment because there are dependencies on systems that are shared across environments. Some massive, redundant filesystem that is sync'd across our data centers, but the sync is a boolean. One datacenter instance of it is the primary and the others are read-only until they get promoted. We have one of these and lower environments are just a different root folder on the system with different access patterns, but they can't make DataCenter A the primary in prod and DataCenter B the primary in UAT.
https://news.ycombinator.com/item?id=50163858
You will probably have issues logging into Llyods even when the cloud is back up.
A lot of the information people are leveraging here comes from Downdetector which is mostly users reporting that stuff is down, not whether they are actually down. It's a really bad source.
If I had a nickel for every solid-green status page I shook my fist at while the actual site faceplanted on every request...
"We would like to apologise for any inconvenience and continue to monitor the situation, which is also affecting other organisations."
They have a stand-in system that uses a separate codebase and separate cloud provider. They have a blog post about it here: https://monzo.com/blog/tolerating-full-cloud-outages-with-mo...
The stand-in system has a limited subset of features, i.e. no bells and whistles, but enough that you can get any actual banking done.
(Not an ad / I have no connection to Monzo, I just had some appreciation for a bank doing this properly as normally banking IT is a disaster. Plus the idea of keeping a separate codebase for almost an entire bank's functionality seems very invested.)
I have always got bad vibes from Revolut...
Multi-cloud is really tough, tbh. It's easier said than done, especially if you care about data consistency at all.
I opened up a Revolut account a couple of years ago with the intention of switching my current account to it (i.e. wages going into it etc), but I got spooked after hearing that they weren't registered as a UK bank and thus subject to the various regulations and protections. I tried using Chase instead and have been happy with it so far.
They are reigistered now
Perhaps this "bank" knows its phones would be down too.
This is affecting companies that put everything into a single GCP region in the UK for their entire business - aka most likely British companies or government with a data sovereignty requirement.
Sovereignty is when there is a UK company with multiple data centres in the country.
With that if one region goes down, another can carry on.
Most European countries have enough space within the country to do that, and, for most things, except banking typically, hosting within the EU is enough, it doesn't have to be within your own country.
A "full function" one in/around London. And a "tickbox" one for multi-region requirements near Cardiff.
The tickbox one has constant capacity constraints and a large number of Azure services aren't in it, but if you need to tick the "two regions and in country" requirement, you kinda/sorta can.
But considering what these sovereignty rules aim to achive, and as someone mentioned, that the problem may be due to companies relying on a single region provided by a hypersclaler due to data sovereignity rules.
Then redundancy has to be considered by both the company and the rulers.
Sovereignty is just where stuff is, not how many place it is there.
But this is supposed to be about practical.
What's the purpose of ticking a box about housing data in UK when you can't make it available after a single incident.
In terms of upfront costs, cloud is always cheaper, initially. There's sort of a weird sweet spot for cloud. If you're to small it makes no sense operationally, if you're to large, it just way to expensive.
Afaik, even Russia and Ukraine aren't having such issues while dealing with data centres getting droned, lol.
It's really quite poor performance.
Can someone ask Claude, Codex, Copilot, Antigravity, Devin to resolve this outage?
No Googling or help from humans this time.
- There's AWS
- There's Azure
- There's everything else
And I don't even use Azure, I just hear it's good (and they don't charge cross-AZ traffic)
Its implementation is clumsy and ugly.
Its documentation is worse.
Its support… isn’t.
The documentation is indeed worst than that still. It’s a maze of articles, none of them actually answer your questions because in Azure the answer to everything is “it depends”. Every doc page has to also be a sales pitch for something. They love inventing skus and features that are basically “now if you want this service to work, you must enable this feature. Otherwise, this is not supported. And to enable this feature, you must delete and recreate your instance” you know, just figure it out.
AWS behind, but with us-east-1 outages.
Azure is extremely far behind those two, and mostly for non-tech legacy shops that got suckered.
I won't touch oracle cloud.