In this article
  1. What happened
  2. Even if you don’t use Google Cloud
  3. How to tell if you’re affected
  4. What to do now
  5. What to set up after

TL;DR: Google Cloud’s London region, europe-west2, has had a multi-service outage since 06:08 UTC on October 20 (2:08 p.m. Manila time), affecting dozens of services including Compute Engine, Cloud Run, Cloud SQL, Cloud Storage, GKE and BigQuery. Google has said “A power event caused an outage within europe-west2-b zone. The power event is mitigated.” As of its update at 12:44 UTC (8:44 p.m. Manila), the incident is still open: Google says it is “seeing the recovery of services for most workloads in europe-west2,” but services in the europe-west2-b zone are still listed as unavailable, and its next update is due by 07:00 Pacific time (14:00 UTC, 10 p.m. Manila). If you run anything in europe-west2, check your Service Health dashboard, fail over only if you’ve already set up a standby in another region, tell your customers, and keep logs for a possible SLA credit claim.

What happened

Google’s public incident says it is “experiencing an issue with multiple services in europe-west2 beginning on Monday, 2026-10-19 23:08 PDT.” That’s 06:08 UTC on Tuesday, October 20, or 2:08 p.m. in Manila. Google first posted the incident on its public status page at 08:35 UTC (4:35 p.m. Manila).

  • Symptoms: “Google Cloud services are unavailable in europe-west2-b zone; some services in europe-west2 region may experience elevated errors and intermittent network issues.” Google’s earlier updates described “elevated errors and intermittent network failures in europe-west2 region.”
  • Where: London (europe-west2) is the only affected location listed. Google says the outage itself was “within europe-west2-b zone.”
  • Status: “Service disruption,” with medium severity, at Google’s 05:44 PDT update (12:44 UTC, 8:44 p.m. Manila). Google says “We are seeing the recovery of services for most workloads in europe-west2 as of Tuesday, 2026-10-20 05:10 PDT” (12:10 UTC, 8:10 p.m. Manila). Its symptoms still say services “are unavailable in europe-west2-b zone.” Its previous update, at 04:58 PDT, said “Customers may not be able to yet create new workloads” and tentatively expected existing workloads to fully recover by 06:00 PDT; the 05:44 update doesn’t repeat either point. Google’s page gives all times in US/Pacific. Google says its next update will come by 07:00 PDT (14:00 UTC, 10 p.m. Manila).
  • Workaround: “If feasible, the impacted customer may try to migrate their workload impacted to another available location (zone or region).”
  • Cause: Google says “A power event caused an outage within europe-west2-b zone.” It first mentioned the power event in its 04:12 PDT update (11:12 UTC, 7:12 p.m. Manila), repeated it at 04:58 PDT, and hasn’t published a fuller explanation. Separately, Hostinger, which runs its control panel on Google Cloud, said on its own status page earlier that “Google notified us the outage was caused by a power failure at one of their data centers.” That’s Hostinger’s account; Google’s incident page doesn’t say it.

Affected products, per Google: AlloyDB for PostgreSQL, Apigee, BigQuery Data Transfer Service, Cloud Data Fusion, Cloud Filestore, Cloud Firestore, Cloud Load Balancing, Cloud Memorystore, Cloud NAT, Cloud Run, Cloud Spanner, Cloud Workstations, Datastream, Google App Engine, Google BigQuery, Google Cloud Bigtable, Google Cloud Dataflow, Google Cloud Dataproc, Google Cloud NetApp Volumes, Google Cloud Pub/Sub, Google Cloud SQL, Google Cloud Storage, Google Compute Engine, Google Kubernetes Engine, Looker (Google Cloud core), Google Cloud Composer (Managed Airflow), Managed Service for Apache Kafka, Memorystore for Memcached, Memorystore for Redis, Memorystore for Redis Cluster, Memorystore for Valkey, Network Connectivity Center, Persistent Disk, Private Service Connect, Speech-to-Text, Storage Transfer Service, VMware Engine and Virtual Private Cloud (VPC). Google’s 02:24 and 04:00 PDT updates noted that “Looker Studio is not impacted by this outage”; its three later updates don’t repeat that note.

Even if you don’t use Google Cloud

You may still be affected through a vendor. Hostinger said its dashboard, service API, Website Builder, Kodee and checkout were unavailable, while “Websites hosted with Hostinger are not affected and continue to work normally.” At 11:42 UTC (7:42 p.m. Manila), Hostinger said “A fix has been applied, and Hostinger Dashboard, the service API, Website Builder, Agent and checkout are available again,” that “Some actions may load slower than usual while recovery completes,” and that it will “post an update once full recovery is confirmed.” It hadn’t posted that update when we last checked, at 9:07 p.m. Manila. Other software you use may run in the same region. If a tool stops working today, check that vendor’s own status page before you start troubleshooting your side. We’ve seen this kind of vendor dependency before with ConnectWise’s Cloud Backup suspension, where customers could only wait for the provider.

How to tell if you’re affected

  1. Check where your resources run. Zones in London are named europe-west2-a, -b and -c. Google says the outage was within europe-west2-b, and that some services in the europe-west2 region may see elevated errors. If none of your projects use europe-west2, this incident shouldn’t touch you directly.
  2. Open the Service Health dashboard in the Google Cloud console. Google calls Personalized Service Health “your primary source for service disruptions relevant to you,” and it shows the incidents tied to your own projects. A Google Cloud support reply on X pointed a customer there for updates, too.
  3. If you can’t sign in, use the public page. Google’s docs say the public Google Cloud Service Health page at status.cloud.google.com needs no login and is the fallback when the console view isn’t available. It also has an RSS feed.

What to do now

  1. Fail over only if you planned for it. If you already run a standby copy of your app and data in another region, follow your failover plan. That’s what Google’s workaround describes.
  2. Don’t rush to move a database. In our view, copying a live database to a new region in the middle of an incident, without a tested replica, risks losing recent writes or ending up with two copies that disagree. If your data is only in London, waiting for recovery is often the safer choice. Restoring from a backup elsewhere means losing anything written since that backup.
  3. Tell your customers. Post a short note on your site or status page: what’s affected, that the cause is a Google Cloud regional incident, and when you’ll update next.
  4. Open or link a support case if you have a support plan. Google says customers with Premium, Enhanced or Standard Support can create a support case, and that you can link a case to a known issue to get regular updates.
  5. Keep a record. Save your error logs, alert times and the times your service was down. You’ll need them for an SLA claim.

What to set up after

  • Claim SLA credits on time. Each Google Cloud product has its own SLA. To get a credit, you have to notify Google technical support yourself: within 60 days for Compute Engine, and within 30 days for Cloud Run and Cloud SQL, according to those products’ SLAs. Compute Engine and Cloud Run also require “log files showing Downtime Periods and the date and time they occurred,” and the credit is applied to future use, not paid out. SLAs exclude errors “caused by factors outside of Google’s reasonable control,” among others. Check the SLA for each product you use on Google’s SLA list.
  • Set up Service Health alerts. In the Service Health dashboard, “Create Alert Policy” offers ready-made templates for new and updated incidents. You need the Service Health API enabled and a Cloud Monitoring notification channel for where alerts go.
  • Decide what needs a second region. Spreading across zones protects you from a single-zone failure. Google says this outage was within one zone, europe-west2-b, but it lists the whole London region as the affected location and says some services in the region may see elevated errors. So a copy in another region is the safer bet for services that must stay up. Pick the one or two services your business can’t be without, and plan a second region just for those.
  • Watch for Google’s incident report. Google says it publishes a public incident report after broad, severe incidents, and that for smaller incidents “a nonpublic report might be made available to customers.” We’ll update this story when Google marks the incident resolved or publishes a report.

Sources & method

Sources

Method. Last checked October 20, 2026, at 9:07 p.m. Manila time (13:07 UTC), against Google’s 05:44 PDT (12:44 UTC) incident update and Hostinger’s 11:42 UTC update. Times, products, symptoms, the power-event cause and Google quotes come from Google’s incident page and docs; the “power failure at one of their data centers” wording and the recovery of Hostinger’s services are Hostinger’s statements and are labelled as such. Manila and UTC times are converted from the Pacific times Google publishes. The advice on databases and second regions is our own judgment. No affiliate links on this page. How we work.

Spotted an error? See our corrections policy and tell us.