At 7:08 on a Tuesday morning, London time, a power event inside one of the three availability zones in Google Cloud's europe-west2 region started a chain reaction. Within hours, Revolut, Lloyds and HSBC customers couldn't log in or make card payments. NHS England services, Royal Mail tracking, Rightmove and parts of the courts' video system went down with them.
The consumer apps got the headlines. The more telling detail was further down the status page: at least 30 Google Cloud services were degraded or failing, including BigQuery, Compute Engine, Kubernetes Engine and the managed Kafka service. That's the analytics stack, not just the front end.
By Wednesday, the European Banking Authority had contacted Google to assess the impact on EU financial firms, and the UK Parliament's Treasury Committee had written to the Bank of England and the FCA asking how they were responding.
This isn't a Google problem. It's an architecture problem.
Every hyperscaler has bad days. Two weeks earlier, Google Cloud Storage in Iowa ran with elevated write errors for more than 12 hours. AWS and Azure have their own histories. Power, cooling and software changes will keep failing, because physical infrastructure does.
The real question for data leaders is simpler: when your provider's region goes dark, does your analytics go dark with it?
For most enterprises, the honest answer is yes. A fully managed, multi-tenant warehouse lives where the vendor put it. Your failure domain is their failure domain. You can't move the engine to another cloud, or to your own data center, for an afternoon. Your recovery plan is a status page and a refresh button.
Why analytics resilience matters more than it used to
Five years ago, a warehouse outage meant a late dashboard. Today the warehouse feeds fraud scoring, regulatory reporting, intraday risk and, increasingly, AI agents that make operational decisions. When it stops, the business stops thinking.
Regulators have noticed. The EU's DORA rules already treat ICT concentration risk as a board-level issue, and the EU designated 19 technology firms as critical third-party providers to finance last year. Tuesday's outage is exactly the scenario those rules were written for. Expect it to show up in supervisory conversations, and expect auditors to ask what your analytics does when one provider has a bad morning.
Four questions to ask about your analytics platform this week
- Where is the failure domain? If your warehouse runs in one vendor's region, list everything that stops when that region stops: reports, models, downstream apps, agents.
- Can the engine run somewhere else? Not "can we export the data," but can the same engine, with the same SQL and the same security model, run in a second cloud or on hardware you control?
- Who decides the topology? With most SaaS warehouses, the vendor chooses zones, regions and tenancy. Resilience you can't configure is resilience you can't prove to an auditor.
- How much rework would a move take? If shifting a workload means rewriting SQL, retesting pipelines and rebuilding access controls, your exit plan is a multi-quarter project, not a contingency.
Where Yellowbrick fits
Yellowbrick was built so the answers to those questions are yours, not your vendor's. It's a massively parallel, PostgreSQL-compatible SQL data warehouse that runs as software on Kubernetes inside your own environment: your AWS, Azure or Google Cloud account, your data center, or the purpose-built Yellowbrick Andromeda appliance.
That changes the resilience conversation in three ways:
- One engine, many locations. The same Yellowbrick runs on all three major clouds and on-premises, so a second site doesn't mean a second platform, a second SQL dialect or a second security model.
- You own the topology. Because Yellowbrick deploys into your accounts and VPCs, your team chooses regions, zones and network design to match your risk posture, and can document those choices for regulators.
- Concentration risk becomes a choice. You can keep critical reporting on infrastructure you control while running other workloads in public cloud, rather than having a single provider sit under everything.
The takeaway
Tuesday's outage lasted hours, not days, and Revolut says customer money and data stayed safe. That's the good news. The uncomfortable news is how many critical services were one power event away from stopping, and how few of their owners could have done anything about it.
Resilience isn't something you can buy as a feature on someone else's platform. It's an architecture you design and control. If your analytics can't run anywhere but your vendor's region, now is the time to change that.
Want to see how Yellowbrick runs across clouds and on-premises with a single engine? Talk to our team.