Google says a power event hit one London zone: 38 products listed, UK banks and courts report faults (20 Oct, 14:18 BST)

A zone failed, and 38 products are listed: what Google's record holds at 14:18 BST

Google's status entry for its London region says that "A power event caused an outage within europe-west2-b zone", one of the region's three zones. The same entry lists 38 products. For the first 5 h 04 min after the start time Google gives, 07:08 BST on Tuesday 20 October 2026 (06:08 UTC), none of its entries named a zone or a cause: the first described elevated errors and intermittent network failures across the whole europe-west2 region, and the first entry to name the zone and the power event was posted at 12:12 BST (derived). At 13:44 BST the entry still said the incident was open. It is a developing incident and everything here is time stamped.

What that does not establish is most of what a reader needs. Google gives no root cause for the power event. It does not say why a failure inside one zone produced symptoms across the region. It does not say how many customers were affected, which customers, or how long any one of them was down. Google's own documentation says that "Zones should be considered a single failure domain within a region" and that it designs zones "to minimize the risk of correlated failures caused by physical infrastructure outages like power, cooling, or networking". A power event in one zone is the case a zone exists for. This briefing sets what Google wrote beside what Google's documents and contracts promise, and beside what UK banks, a court service and a delivery firm said.

Who said what matters here. The BBC reports that banks and websites had problems, and says that "few have explicitly tied problems they are experiencing to the Google Cloud incident". So no firm below is said to have failed because of Google unless that firm or Google says so, and the table of who said what shows which statements name Google (one does). This briefing was built from Google's status feed and incident page, Google's documentation and service level agreements, three earlier Google incident reports for the same region, the BBC, the Guardian, The Register and BleepingComputer, and UK regulator, legislation and Parliament pages. Google's pages were read at 13:37 BST, again midway, and again at 14:18 BST. Where the reporting is secondary, the text says so.

Every status entry, with its time

Google gives the start of the incident as Monday 19 October 2026 23:08 PDT, which is 06:08 UTC and 07:08 BST on Tuesday 20 October (derived from the stated offsets). The incident page states that "All times are US/Pacific". The feed rates the incident's severity as medium and its status impact as SERVICE_DISRUPTION, with one location, London (europe-west2); those labels are Google's and the feed does not define them. The table lists every entry in the status feed and on the incident page. The middle column is the time after that start (derived).

Google Cloud status entries for the europe-west2 incident, read from the status feed and the incident page, 20 October 2026. Times after the start are derived and rounded down to whole minutes.

Entry (BST, UTC, PDT)	After the start (derived)	What the entry says
1. 09:35 BST (08:35 UTC, 01:35 PDT)	2 h 27 min	Symptoms: "Multiple Google Cloud services are experiencing elevated errors and intermittent network failures in europe-west2 region." Workaround: "None for now". Names no zone and no cause. Next update promised by 02:30 PDT.
2. 10:24 BST (09:24 UTC, 02:24 PDT)	3 h 16 min	Same symptoms line, plus "Note: Looker Studio is not impacted by this outage." The workaround now reads "If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region)." Names no zone and no cause. Next update promised by 04:00 PDT.
3. 12:00 BST (11:00 UTC, 04:00 PDT)	4 h 52 min	Same text as the second entry: "Our engineering team continues to investigate the issue." Names no zone and no cause. Next update promised by 05:00 PDT.
4. 12:12 BST (11:12 UTC, 04:12 PDT)	5 h 04 min	First entry to name a zone and a cause: "Due to a power event we had suffered an outage within europe-west2-b zone. The power event is mitigated." Adds that partial mitigation "will be observed within the next 30 minutes". Symptoms now read "Google Cloud services are unavailable in europe-west2-b zone; some services in europe-west2 region may experience elevated errors and intermittent network issues." Next update promised by 05:00 PDT.
5. 12:58 BST (11:58 UTC, 04:58 PDT)	5 h 50 min	"We are seeing the recovery of services and are prioritizing the recovery of existing workloads." Also "Customers may not be able to yet create new workloads." and "Full recovery of existing workloads should be completed, tentatively by Tuesday, 2026-10-20 06:00." Symptoms line unchanged. Next update promised by 06:00 PDT.
6. 13:44 BST (12:44 UTC, 05:44 PDT)	6 h 36 min	"We are seeing the recovery of services for most workloads in europe-west2 as of Tuesday, 2026-10-20 05:10 PDT." The Description no longer mentions the power event, the word mitigated or the 06:00 line. The Symptoms line is unchanged and still says services are unavailable in zone b. Next update promised by 07:00 PDT.

Two readings of one line need settling. The 12:58 BST entry says full recovery should be completed "tentatively by Tuesday, 2026-10-20 06:00" with no time zone. Read as UTC, 06:00 is before the incident began at 06:08 and 5 h 58 min before the entry was written, so it cannot mean UTC. The incident page says all times are US/Pacific and the next line of the same entry promises an update by 06:00 PDT. Read as PDT it is 13:00 UTC and 14:00 BST, 1 h 01 min after the entry was posted (derived). The Guardian's live blog gave that update promise as 06:00 PDT, 2pm BST. The 13:44 BST entry dropped that line and gave a new one: recovery "for most workloads" as of 05:10 PDT, which is 13:10 BST (derived). "Most" is not all, and the entry does not say which workloads are not yet recovering.

Two other timing facts are on the record. Google's updates arrived on or before the time each earlier entry promised, with one exception 28 seconds late (derived from the stated promises and the feed times). And the first entry was created 2 h 27 min 37 s after the start time Google gives (derived). That sounds long, and for a bank's customers it was: the BBC reports more than 1,500 Downdetector reports about Revolut shortly after 08:00 BST, about 52 minutes after the start and about 1 h 35 min before Google's first entry (derived, approximate). But it is not unusual for this feed. The seven other incidents in the status feed, which holds 8 in all, took from 1 h 04 min to 4 days 18 h to reach a first entry, with a median of 3 h 33 min; this incident's 147 minutes is the third shortest of the eight (derived). The start time is the one Google states, so the gap measures Google's posting against its own stated start, not how long anyone was unaware.

One more difference with the press. The BBC's article says the incident was first indicated on the dashboard on Monday evening UK time. The feed's first entry was created at 09:35 BST on Tuesday and the start time is 07:08 BST on Tuesday. The Pacific date of the start time is Monday 19 October (23:08 PDT), which may be the source of the difference (inference). This briefing follows the feed.

What a zone is for, in Google's own words, and the gap in this entry

Google's documentation is plain about what a zone is. The geography page says "Zones should be considered a single failure domain within a region." The Compute Engine page lists three London zones, europe-west2-a, europe-west2-b and europe-west2-c, and says "Google designs zones to minimize the risk of correlated failures caused by physical infrastructure outages like power, cooling, or networking." The reliability guide goes further: "A failure in one zone usually does not affect the resources in the other zones in the region." It adds "The zone merely defines the expected boundary for the effect of a failure." And the disaster recovery guide defines the larger event: "A regional outage is a service interruption affecting more than one zone in a single region."

Google's design targets follow the same ladder. The reliability guide gives 99.9% for a single zone (43.2 minutes in a 30 day month), 99.99% for multiple zones in a region (4.3 minutes) and 99.999% for multiple regions (26 seconds), and says these are targets, not the contractual SLAs, which can differ. On that reading a zone is allowed to fail, and a customer who spread a resource across zones should have kept running. That is a statement about resources, not about every service a customer touches.

Google's documentation set beside this incident's status entries. Sources: the Google pages linked above and the status entries read on 20 October 2026.

Question	Google's documentation says	This incident's entries say, and do not say
What is a zone?	"a single failure domain within a region"	Say: an outage "within europe-west2-b zone". Do not say what part of the zone, or which facility.
What should a zone failure do to the rest of the region?	"usually does not affect the resources in the other zones in the region"	Say: "some services in europe-west2 region may experience elevated errors and intermittent network issues". Do not say which services, or why.
What counts as a regional outage?	"affecting more than one zone in a single region"	Describe one zone. Do not say whether any other zone was affected.
What happens to regional resources when a zone fails?	"Regional resources are resilient to incidents in a specific zone."	List products with regional forms among the 38 (Cloud Run, Cloud Storage, VPC, Cloud Load Balancing). Do not say whether their regional forms were affected.
What happens to a single zone application?	"the application can't serve requests" if it runs in one zone with no failover zone	Do not say how many customers ran that way, or how many failed over.

This region has a history, and Google has published what it learned. Three earlier incident reports for europe-west2 are on Google's status site, and each shows a fault named for one place reaching further. They show that it has happened here before. They do not show why it happened today: today's entries give no mechanism.

Earlier europe-west2 incident reports on Google's own status site, read on 20 October 2026. Durations are as Google states them.

Report	What Google says reached beyond the named place	Cause as Google states it
3 September 2021, zone c, networking, 40 minutes	"Google App Engine and Cloud Run served elevated 500 errors within europe-west2."	"a sudden redirection of traffic from a datacenter that was experiencing an issue"
19 to 20 July 2022, zone a, cooling, 18 h 23 min to restore services and 35 h 15 min for a long tail	"A number of regional Google Cloud services experienced impact during this incident, despite regional services being designed to survive the failure of a single zone." Google names two factors, one of them a routing change: "we inadvertently modified traffic routing for internal services to avoid all three zones in the europe-west2 region, rather than just the impacted europe-west2-a zone."	A "simultaneous failure of multiple, redundant cooling systems in one of the data centers" combined with high outside temperatures
12 August 2024, region, power, 2 h 12 min for cloud products and 40 minutes for Workspace	"ingress traffic to europe-west2 and egress traffic from europe-west2 experienced elevated latencies, connection timeouts, and connection failures." The point of presence held about a third of the region's first layer front end servers.	"primary and backup power feeds were both lost in a Google Point of Presence (POP) due to a substation switchgear failure." Google also said its partner that maintains the facility power was running a root cause analysis.

The 2022 report is the closest to the gap in this entry, and its lesson is narrow. In 2022 Google found that a regional symptom came from an operational decision and a legacy placement rule, not from the zone's physical failure alone. Nothing in today's record says that is what happened now. What it does say, in its own words, is that services in the region saw errors while one zone was down.

38 products, and what the list does not say about which resource was hit

The incident lists 38 affected products. The count is exact, from the status feed, and the grouping below is this site's own, not Google's. A lecturer quoted by the Guardian said "more than 38" services; the feed lists 38. Looker Studio is stated as not impacted, and "Looker (Google Cloud core)" is on the list, which is a different product.

The 38 products on the Google status entry for the europe-west2 incident, grouped by this site. Count and names from the status feed and incident page, 20 October 2026.

Group (this site's)	Count	Products as Google lists them
Compute and containers	6	Google Compute Engine, Google Kubernetes Engine, Cloud Run, Google App Engine, Cloud Workstations, VMWare engine
Storage	5	Google Cloud Storage, Persistent Disk, Cloud Filestore, Google Cloud NetApp Volumes, Storage Transfer Service
Databases	5	Google Cloud SQL, AlloyDB for PostgreSQL, Cloud Spanner, Google Cloud Bigtable, Cloud Firestore
Caches	5	Cloud Memorystore, Memorystore for Memcached, Memorystore for Redis, Memorystore for Redis Cluster, Memorystore for Valkey
Analytics and data	8	Google BigQuery, BigQuery Data Transfer Service, Cloud Data Fusion, Datastream, Google Cloud Dataflow, Google Cloud Dataproc, Looker (Google Cloud core), Managed Airflow
Messaging	2	Google Cloud Pub/Sub, Managed Service for Apache Kafka
Networking	5	Cloud Load Balancing, Cloud NAT, Network Connectivity Center, Private Service Connect, Virtual Private Cloud (VPC)
API and speech	2	Apigee, Speech-to-Text
Total	38	The status feed's affected products list, counted from the feed (derived)

A product name does not say which resource was hit. Google's own examples in the reliability guide show that the same product can have a zonal form and a regional one, and that the form decides what a zone failure does to it. The entry lists products, not forms, so it cannot be used to tell whether a customer's resource was zonal or regional.

Google's own examples of zonal and regional resources, for products that appear in the incident list. Source: Google's reliability guide, building blocks page, read 20 October 2026. A blank means the page gives no example.

Product on the list	Google's example of a zonal form	Google's example of a regional form
Compute Engine	Compute Engine VMs; zonal MIGs	Regional MIGs
Google Kubernetes Engine	Single-zone GKE clusters	Regional GKE clusters with the default (multi-zone) configuration
Cloud Filestore	Filestore Basic and Zonal instances	Filestore Enterprise instances
Cloud SQL	Cloud SQL instances	Not listed as regional on that page; high availability is a configuration (see the SLA below)
Dataflow	Dataflow jobs
Cloud Storage		Regional Cloud Storage buckets
Cloud Run		Cloud Run services
Virtual Private Cloud		VPC subnets
Cloud Load Balancing		Regional external Application Load Balancers
Cloud Spanner		Regional Spanner instances

One more caution. Google's disaster recovery guide says Google "only offers a few zonal resources, namely Compute Engine virtual machines (VMs) and Persistent Disk", while the reliability guide lists more. The two pages were last reviewed on different dates (2024-05-10 and 2026-09-23), so a reader should check the product page for the resource in question.

Who said what in the UK on Tuesday morning

The services below reported problems on Tuesday. Google has named none of its customers. The statements come from the BBC's article and live page, the Guardian's business live blog, The Register and BleepingComputer, all secondary, and are attributed to whoever said them. Firms' own pages and social posts could not be read directly, so every firm statement here is as quoted by the outlet named. Post times are when the outlet posted, not when the statement was made. Downdetector counts reports from users, and the Register's list of firms comes from it, so a firm on that list is a firm users reported problems with, not a firm that has said what caused them.

What UK services said on 20 October 2026, as quoted by the BBC, the Guardian, The Register and BleepingComputer, read between 13:37 and the last read. Names Google means the words quoted name Google or Google Cloud.

Service	What was said, and by whom	Names Google?
Revolut	A spokesperson told the BBC its problems had been caused by a third party issue, and that "all our customers' money and data are safe". BleepingComputer reports that Revolut's status page lists 28 services as affected. An unnamed source told Reuters the outage was related to Google Cloud, as the Guardian relays it in a post at 10:30 BST.	Not in Revolut's own words quoted. Reuters source: yes, unnamed.
Lloyds, Halifax, Bank of Scotland	Lloyds told the BBC (live page post, 11:53 BST) its app was functioning normally but "we understand some are having issues with certain online services this morning". Halifax posted on X, in the Guardian's 11:03 BST post, that it was "aware some customers are having issues with our app and online". The BBC adds "The bank did not confirm whether the issues were caused by the Google Cloud problems."	No.
HSBC	A statement to the BBC (live page post, 13:33 BST): "We are aware that some customers are experiencing difficulties accessing our services." It added that other organisations were also affected.	No.
HM Courts and Tribunals Service (video hearings)	HMCTS said (BBC live page post, 12:08 BST) it was aware of an issue with the video platform used for remote hearings and was "working with our technology partners to restore service", and did not refer directly to Google Cloud, the BBC says. The Criminal Bar Association said the platform was down "since 10am", read here as BST. PA, in the Guardian, says the fault is "believed to be linked to the wider Google outage".	HMCTS: no. PA: believed, not confirmed.
DPD	Aware of "connection issues" with its website; in a post at 13:26 BST the BBC reports DPD said they were resolved.	No.
Emma (budgeting app)	"Emma is currently down due to a Google Cloud outage affecting services in London since 7am." Quoted in the BBC's live page post at 11:19 BST. At 14:02 BST the BBC reports Emma says it is "up and running again".	Yes, in its own words.
Forest (e-bike hire)	The BBC's live page says in a post at 14:10 BST that the service is back to normal and that "A portion of its service was impacted by the Google Cloud outage." Those are the BBC's words; no statement from the firm was quoted.	The BBC's words, not the firm's.
Royal Mail, BT, Cloudflare, Screwfix, Rightmove	Listed by The Register from Downdetector. The Guardian notes Rightmove uses Google Cloud for its AI services. No statement from these firms was read.	Not stated.

So of the firms above, one names Google in its own words, one is reported through an unnamed source, the BBC ties a third (an e-bike hire firm) to the outage without quoting the firm, and the rest said only that something was wrong. That is a finding about the record, not about the cause: a firm can be affected by Google's outage and say only "a third party". The BBC's own reporter says what a single supplier means: services that look separate to customers "actually depend on the same underlying suppliers". The BBC calls europe-west2 Google's only UK cloud region; the zone table on Google's Compute Engine page lists London only for europe-west2, which is consistent but is not a statement about Google's whole estate.

No HMCTS or Ministry of Justice statement on the outage was found on GOV.UK at the time of reading (a search of GOV.UK for the outage and for the video platform returned nothing relevant at 13:46 BST). The words attributed to HMCTS are from its post on X as quoted by the BBC. The PA report in the Guardian adds that a Crown Court trial in London went ahead without the link; this briefing does not name the case.

What the contract promises when one zone fails

A zone is a customer's choice, and the service level agreements follow it. Compute Engine's SLA, last modified 14 October 2026 by its own page, promises 99.99% for instances in multiple zones (Premium tier, outside Stockholm) and 99.9% for a single instance of most machine families. Cloud SQL's SLA covers high availability configurations and says "Shared-core Instances, single-zone Instances, and read pools with 1 node are excluded from the Covered Service."

What two Google SLAs promise, from the SLA pages read on 20 October 2026. Credits are percentages of the monthly bill for the covered service. The sole remedy and the claim windows are as the pages state them.

Covered service	Target	What counts as downtime	Credit and conditions
Compute Engine, instances in multiple zones	>= 99.99%	"loss of external connectivity or persistent disk access" for all applicable running instances	10% for 99.00% to under 99.99%, 25% for 95.00% to under 99.00%, 100% below 95.00%. Claim within 60 days, with logs.
Compute Engine, a single instance (most families)	>= 99.9%	The same loss of connectivity or disk access, for that instance	10% for 95.00% to under 99.90%, 25% for 90.00% to under 95.00%, 100% below 90.00%.
Cloud SQL Enterprise edition with high availability	>= 99.95%	"all Valid Requests to a Cloud SQL Instance with high availability fail"	10% for 99.0% to under 99.95%, 25% for 95.0% to under 99.0%, 50% below 95.0%. Claim within thirty days.
Cloud SQL, a single zone instance	None: excluded from the Covered Service	Not covered	None under the SLA.

Compute Engine's page says "This SLA states Customer's sole and exclusive remedy for any failure by Google to meet the SLO." It excludes errors "caused by factors outside of Google's reasonable control". Whether a power event is such a factor is not stated in the SLA or in any entry. A partner at a law firm told the Guardian that cloud contracts protect the supplier far more than the customer and that "The real exposure sits in the gap between how heavily a business depends on its provider and how little its contract actually guarantees." That is an opinion; the pages above are the contract text.

The arithmetic, derived. October has 31 days, which is 44,640 minutes. A 99.99% target allows 4.464 minutes of downtime in the month, 99.95% allows 22.32 and 99.9% allows 44.64. From the start time to the 12:58 BST entry is 350 minutes. If one Compute Engine instance had met the SLA's definition of downtime for all 350 of them, its Monthly Uptime Percentage would be 99.216%, in the 95.00% to under 99.90% band, which the schedule credits at 10% of that instance's monthly bill. The same window is 8.1 times Google's own 43.2 minute allowance for a single zone in a 30 day month (derived). These are illustrations of how the SLA text works. They are not the duration of any customer's outage, which no source gives, and the SLA's definition of downtime is loss of connectivity or disk access, not errors.

The NCSC's cloud guidance states the limit of a contract in one sentence: an SLA "may provide a mechanism for compensation in the event of outages, but outages will not be prevented if the service design is not appropriate". It also says a provider "usually defines its service level agreements (SLAs) per-service, rather than for the whole of their platform", which is why a platform headline number never describes a customer's stack. The page was published 17 November 2018 and reviewed 7 June 2023, version 2.1.

Seven labels that do the work of a control

A comforting word is not a control. These are the labels in the record on 20 October, and what each one is and is not.

Labels used in the Google entries, the press and the firms' statements, 20 October 2026, with what the sources support.

Label	What it is	What it is not
"power event"	Google's two words for the cause, in entries from 12:12 BST.	A root cause. It gives no location inside the zone, no equipment, no operator. Google's 2024 London report named a substation switchgear failure and a partner that maintains the facility power; this entry names nothing of the kind.
"zone"	A failure domain. A resource sits in one zone or is spread over several, by the customer's choice for most resources.	A guarantee. Google says "If the application runs in a single zone with no failover zone, then when a zone outage occurs, the application can't serve requests."
Multi zone	A placement the SLA recognises: instances "placed across two or more Zones in the same Region".	A property of a product name. The same product can have a zonal form and a regional one, and the entry lists products.
"mitigated"	Google's word for the power event from 12:12 BST.	Recovered. The 12:58 BST entry says customers "may not be able to yet create new workloads"; the 13:44 BST entry says recovery for "most workloads", and its Symptoms line still says services are unavailable in zone b.
"third-party issue"	Revolut's words, as the BBC reports them.	A name. It does not say Google, and a supplier can itself depend on another.
"cloud outage"	One headline for a morning of faults.	One event. A fault at DPD, a bank's app and a court video platform are different services with different architectures; Downdetector counts reports, not causes.
"resilient" and "highly available"	Targets that differ by configuration: 99.9% single zone, 99.99% multiple zones, 99.999% multiple regions in Google's guide.	A whole stack. An SLA is defined per service, and a stack of tiers each at 99.9% has a lower aggregate figure, as Google's guide itself works out.

What the UK regimes say, as read on 20 October 2026

The financial sector has the most specific rules, and they have just changed. HM Treasury's press release of 10 July 2026 names four providers as Critical Third Parties from 13 July 2026: "Microsoft Ireland Operations Limited", "Google Cloud EMEA Limited", "Amazon Web Services EMEA SARL" and "Oracle Corporation UK Limited". That was 99 days before this outage (derived, from 13 July). The release says "Regulatory oversight applies only to the systemic services provided to the financial sector, not firms' wider operations" and "Financial firms remain responsible for managing risks arising from their third-party suppliers."

The Critical Third Parties rules in the FCA Handbook say a designated provider must, "as soon as is practicable after the occurrence of a CTP operational incident and in so far as it is aware at the time of submission", send regulators and affected firms a report. That report covers the nature and extent of the disruption, the time it was detected, the services affected, the geography and, "if known, the cause". The glossary defines the incident to include an event that "causes serious disruption to the delivery of a systemic third party service". Separately, CTPS 4.8.1R requires an incident management playbook, "the first version of which must be in place within 12 months of the critical third party being designated by the Treasury". The rule text sends those reports to regulators and affected firms and does not require them to be published. Whether this incident meets the definition, whether the services involved are systemic third party services and whether Google has filed anything is not on the public record.

For the firms that use the supplier, SYSC 15A.2.9R says "A firm must ensure it can remain within its impact tolerance for each important business service in the event of a severe but plausible disruption to its operations." The PRA's supervisory statement SS1/21 says the PRA expects firms to meet impact tolerances "irrespective of whether or not they use third parties in the delivery of these services", and that a firm "will remain responsible if a third party provider on whom it relies, whether wholly or in part, to provide an important business service, fails to remain within impact tolerances or causes the firm to do so." The deadline for being able to remain within tolerances was 31 March 2025, which is 568 days before 20 October 2026 (derived). The statement quotes SS2/21 as saying a severe but plausible scenario may include "a failure or disruption at a third party, or their supply chain". SYSC 15A.2.11G adds that "the FCA expects to be notified of any failure by a firm to meet an impact tolerance."

Incident reporting is in transition. The FCA's page says firms follow the existing process until the new rules arrive: report to a named supervisor if the incident "Results in a material disruption to the provision of your financial services" or "Affects a large number of customers." The new standardised rules "will come into force on 18 March 2027", which is 149 days after 20 October (derived), so they do not apply to Tuesday's events. The FCA page also points firms to the ICO for data breaches.

Data protection applies to any organisation. UK GDPR Article 32 requires "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services" and "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident". The ICO's guide says there will be a personal data breach "if the data is made unavailable and this unavailability has a significant negative effect on individuals", with notification within 72 hours of becoming aware, where feasible. Whether any organisation's outage on Tuesday meets that test is not stated by any source.

Outside finance, the law is pending. The Cyber Security and Resilience (Network and Information Systems) Bill is in the Lords with report stage listed for 26 October, 6 days after this outage (derived). The Bill as amended in Grand Committee would regulate data centres as essential services at a rated IT load of "equal to or greater than 1 megawatt", or 10 megawatts on an enterprise basis, and its definition of a data centre's supporting infrastructure includes "infrastructure for the supply of electricity". It would also let a competent authority designate critical suppliers. It is not law, and whether the London facility meets a threshold is not stated. The Bill's other gaps are covered in an earlier briefing on its AI text.

The NCSC's guidance is not a rule, but it names this exact gap. Principle 2.5 says a provider "should describe how they ensure resiliency across energy suppliers, cooling systems, telecoms networks" and the impact of an outage of one of those on one or more data centres. The shared responsibility page says "there is a joint responsibility for the security and availability of data and workloads in a cloud service", shared between provider and customer. Google's entry says nothing yet about how its power supply was resilient.

What each regime or body says and what it does not establish about 20 October 2026, from the pages linked above.

Regime	What the page says	Not established on 20 October
PRA SS1/21 and FCA SYSC 15A	Firms must be able to stay within impact tolerance in a severe but plausible disruption, third party or not.	Whether any firm breached a tolerance. No regulator statement on the outage was found.
Critical Third Parties regime	Google Cloud EMEA Limited is designated from 13 July 2026; incident reports go to regulators and affected firms.	Whether this is a CTP operational incident, or whether a report was filed.
FCA incident reporting	Existing process until 18 March 2027; material disruption and large customer numbers are the indicators.	Which firms reported, and what was reported.
UK GDPR and the ICO	Availability and resilience are part of security; unavailability with significant negative effect is a breach.	Whether any breach occurred.
Cyber Security and Resilience Bill	Would regulate data centres by IT load and allow critical supplier designation; not law.	Whether this facility would be covered.
NCSC cloud guidance	Joint responsibility for availability; providers should describe power and cooling resilience.	Google's description of its own power arrangements for this facility.

What to do, in order

Stated and not stated

What the public record holds and does not hold, as of 14:18 BST on 20 October 2026. Sources: the Google status feed and incident page, and the press and regulator pages linked above.

Question	On the record	Not on the record
Root cause of the power event	"A power event caused an outage within europe-west2-b zone."	What the event was, where it happened, who operates the facility, and whether backup power failed.
Why a zone failure reached region wide symptoms	"some services in europe-west2 region may experience elevated errors and intermittent network issues"	Any mechanism. Google's 2022 report gave two; none is given now.
How many customers	Nothing. Thirty eight products are listed.	Any count of customers, projects or resources, zonal or regional.
Which customers	Nothing from Google. One firm, Emma, names Google in its own words.	Any Google confirmation of a named customer, and any confirmation by Revolut, Lloyds Banking Group, HSBC, HMCTS or DPD that Google was the cause.
Total duration	The start time (07:08 BST) and the latest entry at 13:44 BST, 6 h 36 min after the start (derived), with no end time.	When the incident ends, and the duration of any customer's outage.
Any regulator statement	A pre-existing rulebook; Google is a designated Critical Third Party from 13 July 2026.	Any FCA, PRA, Bank of England, ICO or Ministry of Justice statement on this event. None was found.

The commercial interests are plain. Google sells the cloud services it is reporting on and chooses what its status page says. The BBC, the Guardian, The Register and BleepingComputer are news outlets that report what firms say and what users report. The ESET adviser quoted by the Guardian speaks for a security vendor, and the lecturer and the law firm partner are giving opinions. Nothing here is advice on any firm's own position.

The question that exposes the gap

Google's documentation says one zone failing should leave the rest of the region standing, and its own 2022 report shows that sometimes it does not. On Tuesday a zone went dark and, by the record above, firms across the UK reported faults. So here is the question each organisation can answer today, and Google cannot answer for it: if one of three zones in your supplier's region goes dark, which of your important business services stops, which dependency sits in only that zone, and who tells you before your customers do?

What changed while this was written

This briefing was built while the incident was open. Google's status feed was read at the times below, and the text above was rebuilt from the latest read each time. Each read, and what it showed:

• 13:37 BST (first read): Google's latest entry was the one at 12:58 BST (five entries). It named a power event in zone b and said the power event was mitigated. The feed had no end time.
• 13:48 BST (second read): A sixth entry had appeared at 13:44 BST. It said recovery for most workloads as of 05:10 PDT, dropped the power event and 06:00 lines from the Description, kept the Symptoms line, and promised the next update by 07:00 PDT.
• 14:18 BST (final read): Google's feed still held six entries, with no end time. The sixth entry's text was unchanged; only its modified time moved, to 14:09 BST. The BBC live page now carried posts at 14:02 BST (Emma says it is up and running again), 14:10 BST (an e-bike hire firm back to normal, in the BBC's words) and 14:17 BST (Google's recovery update, with the next update at 15:00 BST).

Key facts