On 20 October, a power event at the datacentre hosting Google Cloud’s europe-west2-b zone took that zone offline. It is one of three availability zones in Google’s London region, designed to allow the others to keep running if one experiences a fault. Yet Revolut, HSBC, DPD and Royal Mail were among the organisations reported to have experienced disruption, and critically, the video platform used for remote court hearings in England and Wales also went down.
Google’s preliminary incident report found that the failure caused secondary failover and queuing delays across infrastructure that had not lost power. Google has said it will publish a final report with preventative actions. The engineering findings will be worth reading.
For IT leaders, the most important lesson isn’t that a major cloud provider experienced an outage. It’s that infrastructure resilience and business resilience are not necessarily the same thing. The real test is whether an organisation can maintain or recover its critical services when the infrastructure it depends on becomes unavailable.
A simple place to start is to pick a single zone that hosts part of their estate, work out what would stop working if it went offline, and estimate how long recovery would take.
Find dependencies nobody has mapped
A zone can be well isolated while an application that runs across several zones still depends on just one of them. Applications are built from many parts, including databases, message queues, identity services, DNS and third-party software – if one of them sits in a single zone, the whole service may be exposed to an outage there.
The same applies to suppliers. A payment provider or software-as-a-service tool may run in the affected zone while your own infrastructure sits elsewhere, but your customers will still feel the impact.
One practical way to start is to choose the one service the business could least afford to lose and follow a customer journey through it, from the first click to the final confirmation. For every component along the way, write down which region and zone it runs in and what it depends on in turn, then ask each supplier involved the same question.
What “if feasible” means in practice
During the incident, Google’s advice to affected customers was to migrate impacted workloads to another available location, “if feasible”. Whether that is possible very much depends on decisions made before an outage starts.
The first is authority. Someone needs to be named as able to trigger a failover, and they need to know it. The second is cost – standby capacity and replicated data both appear on the bill, so the decision to move needs a budget holder who has agreed to it in advance. Finally, there is rehearsal. A plan that has never been tested is likely to contain assumptions that only come up under pressure.
A rehearsal can be simple – a scheduled exercise in working hours with someone keeping time and someone taking notes will show how long recovery really takes and where roles or instructions are unclear.
Matching protection to business impact
Not every workload warrants the same level of protection, and paying for the highest tier everywhere is rarely practical for a mid-sized organisation. IT leaders need to make sure they weigh costs of protection against the consequences of downtime.
For each service, ask what happens if it is unavailable for an hour, for four hours and for a day, in terms of revenue, customers, regulatory obligations and staff. The answers set two targets – how long the service can be down, and how much recent data can be lost (commonly called the recovery time and recovery point objectives).
Services will often fall into three groups. Those that the business cannot do without justify running across multiple zones, with a failover that has been tested. The middle group can usually be restored from backups into another zone or region within an agreed time. The remainder can be rebuilt from code and backups, and an outage of several hours is acceptable for them.
Resilience shouldn’t be measured by how much an organisation spends on redundancy, but by whether that investment reflects the commercial impact of downtime. Protecting every workload to the highest possible standard is rarely practical or financially justified. The objective should be to invest proportionately to ensure the services most critical to revenue, customers and operations receive the greatest protection.
Cloud resilience operates on a shared-responsibility model. While providers are accountable for the infrastructure and services they deliver, organisations remain responsible for understanding how their applications are architected, where dependencies exist and whether recovery strategies meet business requirements. The big AWS outage in the US in October 2025 was a reminder that disruption can extend beyond the infrastructure where a fault begins.
Agree recovery responsibilities with cloud and support partners
Most critical services depend on several parties, whether a hyperscale provider, a managed service provider, a software vendor or an internal platform team. During an incident, delays often come from uncertainty over who is responsible for each step. It helps to record that division of responsibility for every critical workload in a straightforward format. At a minimum, it should show where the workload runs, which services it relies on, who has failover authority, and committed response times for each party.
Technology partners should play a proactive role in this process. Beyond responding to incidents, they should help customers challenge assumptions about their environments, identify single points of failure and assess whether the cost of additional resilience is justified by the business risk it mitigates. A partner supporting the environment should be able to produce that evidence, along with a costed view of moving a given service to a higher tier of protection. This gives IT leaders a clearer picture of the protection they have, gaps that remain and the cost to address them.
Settling decisions before the next incident
Power faults, software changes and human error can interrupt cloud services on any provider, and the Google Cloud incident shows how far the effects can travel beyond the zone where a fault begins. No business can prevent every outage, but can look at how much disruption its business can tolerate and prepare accordingly. Leaders need to be clear about which services matter most, what level of recovery each one requires and who is accountable for acting when a provider’s status page starts to change.
Those decisions need to be revisited as the business and its systems change. A team that has agreed costs, assigned responsibility and rehearsed its recovery steps is better placed to respond when the next incident occurs than one trying to work out what to do under pressure.
The next major cloud outage is a question of when, not if. The organisations that navigate it most effectively won’t necessarily be those spending the most on infrastructure, but those that understand their dependencies, have made informed investment decisions and have tested their ability to recover. For technology leaders, the question is simple: if a critical cloud service failed tomorrow, could you demonstrate that your business is ready?
Justin Sharrocks is general manager EMEA at TrustedTech
