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)
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.
1. AWS has no cross-regional or cross-zonal data plane[1] dependencies. Customers might couple them, in violation of best practices, but AWS itself does not. It's strictly forbidden.
2. That article you linked to does not support your claim. That is a report of a single-zone incident impacting us-east-1 only. Five other AZs in the same region were still fully operational.
[1] These are not the same as control plane dependencies: you might not be able to make certain mutations, but everything should still work in the steady state.
People who don't work on cloud services are usually very sloppy with their wording which I think is leading to some disconnect here. A "zone" is not really the unit of availability for most things people consider the "cloud" for hyperscalers. A zone is like 1-3 DCs and you are very vulnerable to stuff like localized power events. For that reason most services are not offered at the zonal level and if they are you get big disclaimers saying so and lower 9s of SLA.
Most things are at a regional level which is multiple zones. Your AWS us-east-1 is one such region. A lot of datacenters spread across a decently large physical area have to have an issue for a whole region to start having failures.
For GCP it seems like one power event in a DC led to a thundering herd on the rest of the region which was the actual issue here. (which is a pretty significant problem and isn't supposed to happen)
> 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.
I'd imagine (maybe optimistically) most companies do think about using multiple zones. And even test for DR. Regularly. And successfully. Problem is, all that works just fine on a sunny Monday morning. Then shit hits the fan and all of a sudden everyone is forced to, at the same time. It's a different kettle of fish
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.
Other clouds are similarly odd (or even worse). I have experienced in Azure that if you provision a resource group with some basic SKU for a given service, the only way to later upgrade to the latest and greatest SKU is to tear down the whole resource group and re-provision everything from scratch. All attempts at scale-up in place will fail with cryptic errors. Seems like you are assigned in an old corner of the DC and can't get out of it.
Extra fun if there is a key vault involved, then you have to manually delete every key in it, otherwise you can't create new keys with the same names in the new vault.
Yes. The area on the Venn diagram where services, hardware and regulatory compliance intersect is surprisingly small.
I had a client that was contracting with a very large bank and there were only something like four zones globally that we could possibly deploy in to.
Google also is unlike AWS in that their zone abstraction is very virtual, and two zones might be in the same physical building. If you have requirements that your deployment zones be physically separated by some minimal distance then it can make things pretty challenging.
From the documentation of the Google Cloud Platform.
> To protect against the loss of an entire region due to natural disaster, have a disaster recovery plan and know how to bring up your application in the unlikely event that your primary region is lost.
> The regions Stockholm, Osaka, and Montreal have three zones housed in one or two physical data centers.
It comes across as really uncaring to the probably 99.9999% of people outside of the US who have no idea offhand what UTC offset it is, it almost feels hostile.
If they at least included “(UTC -7)” after PDT, while still a bit annoying, at least people could work out what time that is without having to lookup PDT from somewhere first (as I just had to).
The fact they didn't immediately fail over doesn't mean they didn't had a plan.
The plan might've just been "if it gets bombed, we restore backups into other zone". Just waiting for it to fix itself for few hours mightv'e been acceptable risk.
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.
>> 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.
Well then you should know that a Google Zone is not the same as an AWS AZ and many of Google regions are just firewalls across the same data center.... Despite all their SREs and Books and Phds...they dont know how to do infrastructure.
For sure Google zones aren't the same as AWS AZs, and I remember complaining about this years ago during that fire in a France DC. But you also said their regions are firewalls across a datacenter, suggesting a multi-region DC, which I'm pretty sure they don't have.
The overall point is accurate. Google expects you to spread things more across zones. Most users would rather zones not share buildings.
> ... I'm amazed the big companies reported as down weren't using multiple zones.
Yeah well, they drank the cloud kool-aid. The promise was that they'd go "cloud", and that everything would be taken care of.
Turns out: availability is worse than when those companies used to self-host and major cloud outages are happening all the time (at this point it's basically a meme).
And now the promise that "the cloud is simpler than doing it yourself" turns out to be not true?
I'm not surprised at all: these companies have been sold a lie.
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.
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.
Help me understand, is the bad vibes you get from stories from the company culture? Or rather that the media put a target on their back (at at least in my opinion this is because they have a Russian born founder? Revolut is one of the best products I've ever used, I've honestly nothing but good things to say about them.
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 couldn't pay for groceries with Revolut in a store. Staff asked if I was using Revolut, but luckily adding a card from a different bank to Apple Pay was quick and painless (I had neither my wallet nor cash with me).
Another reminder that we need redundancy for all essential services that we rely on.
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.
I've found that it's better than most service status pages -- Downdetector shows when users are reporting problems, while most service status pages only post significant confirmed outages, but there can still be service affecting issues that don't show up on the status page yet (or ever)
It's a really bad source compared to what? Downdetector is not perfect, but is usually correct when I check it. Official status pages on the other hand are usually wrong when I check them.
“Correct” here presumably means “some other people are also experiencing problems.” For companies like large banks, with tens of millions of customers, that’s not necessarily very meaningful except for the people who happen to be experiencing the issue.
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.
Possibly the most surprising part of this is the extremely quiet reporting on it. I've not seen many news outlets pick it up, & even on HN - they were down for almost 8 hours & I didn't see even see this post hit the frontpage (it might have briefly at some stage).
I guess service reliability is just no longer something we consider a big deal in today's tech landscape.
A ton of people in Switzerland use revolut and where effected. Why people still use Revolut as their primary bank is beyond me. Not a "bank" I trust especially after what I have heard and seen.
Anyone have a read on the implications for Digital Operational Resilience Act (DORA) compliance here? Google Cloud seems to be a critical third-party vendor for these financial institutions. The top penalties for DORA can be very expensive (% of worldwide revenue fines).
Depends on where the EU-licensed institution is headquartered, as monitoring is done by the states. But I'll say it's very likely that there will be an angry call or a review at most. Some manager will have to write up how they want to mitigate problems in the future, and this plan is maybe implemented in the next few years. If this is the first problem of an institution, a fine is rather unlikely.
Generally with acts like these: You don't have to be fully compliant in practice. You need to know how compliant you are, have a plan to improve things, and prove that you are working on it. But if you are "close enough" (depending on who audits you), non-compliance isn't a direct route to fines.
> Makes me wonder why an EU bank is keeping data outside the EU (from my understanding, only the London data center is down)?
Let me tell you a story about an idiot politician who woke up one day and thought Brexit would be a fantastic idea, and then the stupid dim-witted "ultra-hard brexit" manner in which it was implemented by a certain Mr Johnson.
The same reason UK people can't open EU bank accounts is the same reason EU banks have separate operating companies and infrastructure in the UK.
Given they operate in a heavily-regulated environment it almost certainly made life easier for them to keep UK stuff in the UK because they had no idea how (or if) the regulatory environment would ever progress beyond ultra-hard brexit.
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.
It's not "going down", the servers just went on strike in solidarity with europe-west9 (Paris) to protest against too much server uptime past 5 PM, thermal abuse, low voltages and mass PID killings. Americans won't understand. Additionally the failover data packets got stuck in customs for inspection and had to form a line back to Dover. So yeah, bad day innit.
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.
If you log in onto machine and make an error, a machine is down.
If you put everything into configuration management, make scalable, redundant and interconnected servers and services built on top of it, you unlock amazing possibility of one error bringing hundreds if not thousands machines down.
Nice lil reminder that adding more things for redundancy only increases it if they are entirely unrelated to eachother and independent.
Which INCLUDES not running same software. You can have redundant switches, doesn't matter if they have software bug that triggers on all of them (or just one in a way that prevents network from working correctly).
You can have database cluster that can tolerate node dying just fine but still be brought down by a bug despise redundancy.
Let me draw a line between this and the Ukrainian bombing of Russian Yandex data centers. This is a sign of structural vulnerability. If one power failure can take down more than 5 banks, what you are describing is a valuable target. It's ironic that the cloud services that promised to harden systems have delivered another layer of vulnerability.
> If one power failure can take down more than 5 banks, what you are describing is a valuable target. It's ironic that the cloud services that promised to harden systems have delivered another layer of vulnerability.
Fair, but if all of those 5 banks bought their own servers and put them into a datacenter that happens to be same one because it's the fancy one that meets all the bank regulations and required certs, that datacenter going down would still make 5 banks go down.
You would got some resiliency by fact only datacenter related issues (power, internet access) would affect it and not say "cloud company throwing AI at their code that proceeds to explode" (which already happened), but still, if you want to fix that, cloud or not, you have to have multiple locations/regions and that's both costly and difficult.
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.
IME the diferent components of Azure vary quite a bit. Some of them are great, others are pretty inconvenient or weirdly designed. I personally feel the web UI is terrible. I like that the APIs follow consistent rules and seem to follow good practices across the board. The documentation is hit or miss, kind of like the components themselves.
Honestly that's kind of been my experience with all of the cloud providers I've had to work with.
From Google's status page https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPy...
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)
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.
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...
1. AWS has no cross-regional or cross-zonal data plane[1] dependencies. Customers might couple them, in violation of best practices, but AWS itself does not. It's strictly forbidden.
2. That article you linked to does not support your claim. That is a report of a single-zone incident impacting us-east-1 only. Five other AZs in the same region were still fully operational.
[1] These are not the same as control plane dependencies: you might not be able to make certain mutations, but everything should still work in the steady state.
In Google Cloud, that's a huge no no and you'll be put on a naughty list facing serious scrutiny during the postmortem review.
Disclaimer: I work for Google Cloud.
12 replies →
People who don't work on cloud services are usually very sloppy with their wording which I think is leading to some disconnect here. A "zone" is not really the unit of availability for most things people consider the "cloud" for hyperscalers. A zone is like 1-3 DCs and you are very vulnerable to stuff like localized power events. For that reason most services are not offered at the zonal level and if they are you get big disclaimers saying so and lower 9s of SLA.
Most things are at a regional level which is multiple zones. Your AWS us-east-1 is one such region. A lot of datacenters spread across a decently large physical area have to have an issue for a whole region to start having failures.
For GCP it seems like one power event in a DC led to a thundering herd on the rest of the region which was the actual issue here. (which is a pretty significant problem and isn't supposed to happen)
10 replies →
Worked at a major ISP in the 90s with many critical infra customers. True diversity is a lot harder than many imagine.
> 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.
5 replies →
I'd imagine (maybe optimistically) most companies do think about using multiple zones. And even test for DR. Regularly. And successfully. Problem is, all that works just fine on a sunny Monday morning. Then shit hits the fan and all of a sudden everyone is forced to, at the same time. It's a different kettle of fish
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.
Other clouds are similarly odd (or even worse). I have experienced in Azure that if you provision a resource group with some basic SKU for a given service, the only way to later upgrade to the latest and greatest SKU is to tear down the whole resource group and re-provision everything from scratch. All attempts at scale-up in place will fail with cryptic errors. Seems like you are assigned in an old corner of the DC and can't get out of it.
Extra fun if there is a key vault involved, then you have to manually delete every key in it, otherwise you can't create new keys with the same names in the new vault.
1 reply →
Yes. The area on the Venn diagram where services, hardware and regulatory compliance intersect is surprisingly small.
I had a client that was contracting with a very large bank and there were only something like four zones globally that we could possibly deploy in to.
Google also is unlike AWS in that their zone abstraction is very virtual, and two zones might be in the same physical building. If you have requirements that your deployment zones be physically separated by some minimal distance then it can make things pretty challenging.
1 reply →
> infrastructure code for GCP that interrogated hardware availability
How do you to do that ?
1 reply →
From the documentation of the Google Cloud Platform.
> To protect against the loss of an entire region due to natural disaster, have a disaster recovery plan and know how to bring up your application in the unlikely event that your primary region is lost.
> The regions Stockholm, Osaka, and Montreal have three zones housed in one or two physical data centers.
See here: https://docs.cloud.google.com/docs/geography-and-regions
2023 europe-west9 incident: https://www.datacenterdynamics.com/en/news/water-leak-at-par...
Google is PDT-centric, and never grew out of it. Everything is Mountain View time internally and it's so jarring.
It comes across as really uncaring to the probably 99.9999% of people outside of the US who have no idea offhand what UTC offset it is, it almost feels hostile.
If they at least included “(UTC -7)” after PDT, while still a bit annoying, at least people could work out what time that is without having to lookup PDT from somewhere first (as I just had to).
8 replies →
The fact they didn't immediately fail over doesn't mean they didn't had a plan.
The plan might've just been "if it gets bombed, we restore backups into other zone". Just waiting for it to fix itself for few hours mightv'e been acceptable risk.
And what about the fact this give the US government?
1) the ability to view everyone's bank data, in secret
2) the ability to change EU bank data at will, in secret
(see US Cloud act)
There are much worse things you can do to data than bomb it.
> https://news.ycombinator.com/item?id=50163858
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.
The drawback being temptation not to power them indepedently, it seems.
>> 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.
Well then you should know that a Google Zone is not the same as an AWS AZ and many of Google regions are just firewalls across the same data center.... Despite all their SREs and Books and Phds...they dont know how to do infrastructure.
For sure Google zones aren't the same as AWS AZs, and I remember complaining about this years ago during that fire in a France DC. But you also said their regions are firewalls across a datacenter, suggesting a multi-region DC, which I'm pretty sure they don't have.
The overall point is accurate. Google expects you to spread things more across zones. Most users would rather zones not share buildings.
Dont downvote...read their docs....and this is just the start:
"The regions Stockholm, Osaka, and Montreal have three zones housed in one or two physical data centers." - https://docs.cloud.google.com/docs/geography-and-regions
"This means the multiple zones within each of these regions may not be located in physically separate data center campuses." - https://docs.cloud.google.com/backup-disaster-recovery/docs/...
"A region is a set of buildings operated by Google in a geographic location, such as a data center campus." - https://cloud.google.com/vpc/network-pricing
I know some banks out-sourced most of its infrastructure to external operators, and some operator I worked with didn't seem competent.
> ... I'm amazed the big companies reported as down weren't using multiple zones.
Yeah well, they drank the cloud kool-aid. The promise was that they'd go "cloud", and that everything would be taken care of.
Turns out: availability is worse than when those companies used to self-host and major cloud outages are happening all the time (at this point it's basically a meme).
And now the promise that "the cloud is simpler than doing it yourself" turns out to be not true?
I'm not surprised at all: these companies have been sold a lie.
>>Google cloud outage takes down HSBC, Revolut, Bank of Scotland, Llyods, Equifax, more
You will probably have issues logging into Llyods even when the cloud is back up.
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.
Strange. My Lloyds login has never failed since I opened the account 11 years ago.
The usability of their mobile app is atrocious though. Good thing they have a website.
Do you have an account with Llyods though?
cannot agree more
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.
Not all neobanks. I use Monzo, and they had an outage a while back. I was impressed that it barely affected their functionality.
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...
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.
3 replies →
> I have always got bad vibes from Revolut...
Help me understand, is the bad vibes you get from stories from the company culture? Or rather that the media put a target on their back (at at least in my opinion this is because they have a Russian born founder? Revolut is one of the best products I've ever used, I've honestly nothing but good things to say about them.
1 reply →
> I have always got bad vibes from Revolut...
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.
6 replies →
I couldn't pay for groceries with Revolut in a store. Staff asked if I was using Revolut, but luckily adding a card from a different bank to Apple Pay was quick and painless (I had neither my wallet nor cash with me).
Another reminder that we need redundancy for all essential services that we rely on.
cash is a more reliable redundancy.
> there's no phone number to call
Perhaps this "bank" knows its phones would be down too.
The EU should really prioritise building AWS and Google Cloud alternatives with European values.
> ssh root@eu-cloud
This is being done while we speak here.
Happily hosting a site that will cross 4 billion queries per year there, and I didn’t face that banner you mention :-)
Two things:
1) 4b queries a year is nothing. 4b queries is less than an hour for some of the software I have written.
2) The banner was a joke referencing the fact that the EU has a terrible track record with privacy.
Wrong answer.
There is literally no sensible reason that a bank should use another companies computers.
Yeah but i wish most of those weren't glorified OpenStack wrappers.
I bank with HSBC. Everything is up and working.
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.
Exactly. "Responding to pings" is not the same as "letting me get work done".
If I had a nickel for every solid-green status page I shook my fist at while the actual site faceplanted on every request...
I've found that it's better than most service status pages -- Downdetector shows when users are reporting problems, while most service status pages only post significant confirmed outages, but there can still be service affecting issues that don't show up on the status page yet (or ever)
It's a really bad source compared to what? Downdetector is not perfect, but is usually correct when I check it. Official status pages on the other hand are usually wrong when I check them.
“Correct” here presumably means “some other people are also experiencing problems.” For companies like large banks, with tens of millions of customers, that’s not necessarily very meaningful except for the people who happen to be experiencing the issue.
2 replies →
Alternatively, and from the top of the HSBC homepage
"We would like to apologise for any inconvenience and continue to monitor the situation, which is also affecting other organisations."
They're always up with cartel cash.
Countries talking about AI sovereignty, when they forgot compute sovereignty
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.
That's not sovereignty.
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.
14 replies →
I think people have been fighting Googles monopolies for quite some time
Which you can't. Unless the government steps in and demands that all ties with Burgerland are cut.
Possibly the most surprising part of this is the extremely quiet reporting on it. I've not seen many news outlets pick it up, & even on HN - they were down for almost 8 hours & I didn't see even see this post hit the frontpage (it might have briefly at some stage).
I guess service reliability is just no longer something we consider a big deal in today's tech landscape.
That's not the whole. That's the UK. I use banking services in Switzerland, built on GCP. No interruption at all. Been travelling all day.
A ton of people in Switzerland use revolut and where effected. Why people still use Revolut as their primary bank is beyond me. Not a "bank" I trust especially after what I have heard and seen.
https://www.srf.ch/play/tv/kassensturz/video/internetbank-re...
Indeed. The banks I deal with in France are unaffected.
Anyone have a read on the implications for Digital Operational Resilience Act (DORA) compliance here? Google Cloud seems to be a critical third-party vendor for these financial institutions. The top penalties for DORA can be very expensive (% of worldwide revenue fines).
Depends on where the EU-licensed institution is headquartered, as monitoring is done by the states. But I'll say it's very likely that there will be an angry call or a review at most. Some manager will have to write up how they want to mitigate problems in the future, and this plan is maybe implemented in the next few years. If this is the first problem of an institution, a fine is rather unlikely.
Generally with acts like these: You don't have to be fully compliant in practice. You need to know how compliant you are, have a plan to improve things, and prove that you are working on it. But if you are "close enough" (depending on who audits you), non-compliance isn't a direct route to fines.
europe-west-2 is in London, which is not in the EU.
You can't hurt our mainframe running COBOL. Suck it zoomers!
IBM sales people entered the chat.
They need to talk about some updates to the maintenance interact pricing...
Nobody has never been fired for using ~~IBM~~ ~~Oracle~~ Google.
I wonder if it's somehow related to me having to re-sign into my account after clearing Google Play Services data just a few hours ago.
Most likely it knocked out the "Ing" bank in Germany.
Makes me wonder why an EU bank is keeping data outside the EU (from my understanding, only the London data center is down)?
> Makes me wonder why an EU bank is keeping data outside the EU (from my understanding, only the London data center is down)?
Let me tell you a story about an idiot politician who woke up one day and thought Brexit would be a fantastic idea, and then the stupid dim-witted "ultra-hard brexit" manner in which it was implemented by a certain Mr Johnson.
The same reason UK people can't open EU bank accounts is the same reason EU banks have separate operating companies and infrastructure in the UK.
Given they operate in a heavily-regulated environment it almost certainly made life easier for them to keep UK stuff in the UK because they had no idea how (or if) the regulatory environment would ever progress beyond ultra-hard brexit.
1 reply →
Maybe they mix it: serving fonts/pictures/etc over scalable cloud providers and hosting confidential data themself.
The ING outage was unrelated to Google's.
I couldn't unlock a shared city bike this morning on the Beryl system, probably the same outage.
Own not rent is always the better option.
Ah again London region :D
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.
It's really quite poor performance.
I've worked for a UK financial institution before. If you knew, you would keep your money under a mattress.
>Afaik, even Russia and Ukraine aren't having such issues while dealing with data centres getting droned, lol.
Not having issues is overstatment, but Ukraine has a cheat of having a backup DC on NATO soil, which helps a lot.
> Afaik, even Russia and Ukraine aren't having such issues while dealing with data centres getting droned, lol.
They've had ~5yr to work on that.
London - having given itself a crown of 'financial capital', has had faaaaar longer, with a lot more resources. There's no excuse.
The government should be resilience testing everything. Did Covid teach no lessons? Is the defence budget just for shits and giggles?
1 reply →
how can cloud inf go down? that was the main selling point, it makes no sense
It's not "going down", the servers just went on strike in solidarity with europe-west9 (Paris) to protest against too much server uptime past 5 PM, thermal abuse, low voltages and mass PID killings. Americans won't understand. Additionally the failover data packets got stuck in customs for inspection and had to form a line back to Dover. So yeah, bad day innit.
Cloud is just an really expensive vps with an api, you still got to leverage that api to replicate your service
It's literally just a bunch of computers in a couple of expensive buildings. Of course it can go down.
You still have to design for outages. It's when, not if. Bad things happen - fires, floods, power outages etc.
Sounds like most of these companies were not designed to handle outages in a single availability zone, and so they went down.
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.
2 replies →
It makes no sense only if you believe in magic and marketing
>clown infra
If you log in onto machine and make an error, a machine is down.
If you put everything into configuration management, make scalable, redundant and interconnected servers and services built on top of it, you unlock amazing possibility of one error bringing hundreds if not thousands machines down.
Nice lil reminder that adding more things for redundancy only increases it if they are entirely unrelated to eachother and independent.
Which INCLUDES not running same software. You can have redundant switches, doesn't matter if they have software bug that triggers on all of them (or just one in a way that prevents network from working correctly).
You can have database cluster that can tolerate node dying just fine but still be brought down by a bug despise redundancy.
Since there are no humans working on outages here is the test for superintelligence:
Can someone ask Claude, Codex, Copilot, Antigravity, Devin to resolve this outage?
No Googling or help from humans this time.
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
Let me draw a line between this and the Ukrainian bombing of Russian Yandex data centers. This is a sign of structural vulnerability. If one power failure can take down more than 5 banks, what you are describing is a valuable target. It's ironic that the cloud services that promised to harden systems have delivered another layer of vulnerability.
> If one power failure can take down more than 5 banks, what you are describing is a valuable target. It's ironic that the cloud services that promised to harden systems have delivered another layer of vulnerability.
Fair, but if all of those 5 banks bought their own servers and put them into a datacenter that happens to be same one because it's the fancy one that meets all the bank regulations and required certs, that datacenter going down would still make 5 banks go down.
You would got some resiliency by fact only datacenter related issues (power, internet access) would affect it and not say "cloud company throwing AI at their code that proceeds to explode" (which already happened), but still, if you want to fix that, cloud or not, you have to have multiple locations/regions and that's both costly and difficult.
> It's ironic that the cloud services that promised to harden systems have delivered another layer of vulnerability.
You misunderstand.
This is a provider outage, but the services running on them by the customers (that went offline) were not designed or setup to be multi-region.
The infra outage is GCPs fault, but application outages from customers are caused by their architecture and decisions prior to the outage.
[dead]
Terry? Terry wrist?
Migrate to the Cloud, they said. It will be more resilient and less expensive, they said.
Who's "they"? Someone from [cloud]'s professional services?
I think so indeed ;-)
Blockchain does not have this problem.
Ironic: yesterday X Money invited me to open an account — with a starting gift balance of $15. Deeper currents?
At this point, the way I see it is:
- 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)
GCP has by far had the least amount of outages and seemingly the best security.
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.
I see the GCP marketing staff has found HN.
Azure’s design is elegant and even — dare I say it — beautiful.
Its implementation is clumsy and ugly.
Its documentation is worse.
Its support… isn’t.
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.
IME the diferent components of Azure vary quite a bit. Some of them are great, others are pretty inconvenient or weirdly designed. I personally feel the web UI is terrible. I like that the APIs follow consistent rules and seem to follow good practices across the board. The documentation is hit or miss, kind of like the components themselves.
Honestly that's kind of been my experience with all of the cloud providers I've had to work with.
1 reply →