The London outage of 20 October 2026: nine status pages, one Google Cloud zone

A power event in Google Cloud's europe-west2-b zone hit Kinsta, Aiven, Elastic Cloud, Cloudways, MongoDB Atlas, ClickHouse Cloud, CockroachDB and Confluent. When each status page posted, what Vigil could and could not see, and the single-region lesson.

On 20 October 2026 a power event in one zone of Google Cloud's London region, europe-west2-b, took down or degraded services for a whole morning. Eight other companies posted incidents about it on their own status pages. This page puts their notices side by side, using only what the vendors published and what Vigil stored from their status pages. Every time below is in UTC and comes from the linked page.

What Google said

Google's incident, Multiple services are experiencing issues in the europe-west2 region, says the problem began at 23:08 PDT on 19 October, which is 06:08 UTC on 20 October. Its first public update is timestamped 08:35 UTC. At 11:12 UTC Google wrote that "a power event" had caused an outage in the europe-west2-b zone and that the power event was mitigated. At 14:03 UTC it marked the issue mitigated for most customers, with an end time of 14:00 UTC. The incident lists 38 affected Google Cloud products in London (europe-west2), from Compute Engine and Cloud SQL to Pub/Sub and Kubernetes Engine.

When each status page posted

Two things stand out from the vendors' own timestamps:

• Every one of the eight downstream vendors posted before Google did. Kinsta's first post came at 06:40, almost two hours before Google's first update at 08:35. If you only watched your cloud provider's status page, you heard about this later than the customers of the companies built on top of it.
• Recovery did not end when Google's incident ended. Google gave 14:00 as its end time. Aiven resolved at 19:30, Confluent at 18:27 and MongoDB Atlas at 20:09, and Elastic Cloud and Cloudways still had open incidents at 20:55. Restarting clusters, re-syncing replicas and recovering nodes takes time after the power comes back.

Cloudways' notice names "our upstream provider in the London region" without naming the provider, so we only list it here because it was posted the same morning about the same region.

What Vigil saw, and what it could not see

Vigil reads the status pages of the services in its Is it down? catalogue every 5 minutes and stores each reading. For this event:

• Google Cloud: every reading from 06:04 to 08:30 said "All services available". The first reading that showed the incident was at 08:36, a minute after Google's first update. The last was at 14:04, and at 14:09 the page was back to "All services available". So our record of Google's page matches what Google published; it cannot show anything earlier than Google did. See Is Google Cloud down?.
• MongoDB Atlas: the overall indicator on Atlas's status page read "All Systems Operational" in every reading between 06:02 and 20:55 (two readings timed out), while Atlas had an open incident from 07:32 to 20:09. Atlas posted the incident with a "minor" impact, and the page's overall indicator did not change. Vigil's dependency monitors read that overall indicator, so a Vigil dependency monitor on Atlas would not have alerted for this incident. See Is MongoDB Atlas down?.
• Cloudways: we only started reading Cloudways' page at 18:52, when we added it to the catalogue. Every reading since then said "All Systems Operational" while its London incident was still open.
• The others (Kinsta, Elastic Cloud, CockroachDB, Confluent, Aiven, ClickHouse Cloud) were not in our catalogue on 20 October. Kinsta, Elastic Cloud, CockroachDB and Confluent were added on 21 October.

We could not observe the regional outage itself. Vigil's own checks run from one location: a server at Hetzner in Falkenstein, Germany. A failed zone in London is invisible from there unless the thing we check is hosted in that zone, and none of our direct checks were. We have no measurements of our own for this outage, which is why every time on this page comes from a vendor.

The lesson: a single region is a single point of failure

The vendors' notices show the difference that spreading out made. MongoDB wrote at 07:32 that Atlas clusters are spread across several availability zones, so 3-node clusters "can continue to serve reads and writes from nodes in the other 2 Availability Zones in this region". Elastic wrote that deployments "with resources in the affected zone" were unavailable or degraded. The zone failed for everyone; whether customers noticed depended on what else their service ran on.

What to take from it:

1. Know where your providers run you. For each provider that matters (database, hosting, queue, search), write down the region and, where you can see it, the zones. Most of the notices above only make sense if you know you are in europe-west2.
2. Use more than one zone, and for the parts you cannot lose, more than one region. A multi-zone database cluster or a second region costs money; compare it with a lost morning of business.
3. Watch incidents, not only the green light. An overall indicator can stay "All Systems Operational" while an incident for your region is open, as Atlas's did. Subscribe to the provider's incident notifications (email, RSS or webhook) for the components and regions you use.
4. Check your own service from outside, from more than one place. A check from one location, like Vigil's hosted checks, only tells you what is reachable from there. Add a check from near your users, for example with a Vigil private location (an agent on a small server you run in another region), or with a second service.
5. Tell your own customers. When your provider has a bad morning, your customers ask you, not Google. A status page on your own domain lets you post one update instead of answering the same question all day.

Sources

Every incident page linked in the table above, read on 20 October 2026, and the stored status-page readings behind Is Google Cloud down?, Is MongoDB Atlas down? and Is Cloudways down?. Times are as published by each vendor; incidents still open will change after this was written.

More guides

• How to monitor PostgreSQL connections, cache hit ratio and replication lag (and get paged before it hurts)
• See every API your server calls (and every call it receives) without changing a line of code
• Self-hosting a full monitoring stack in one command: servers, logs, APM and status pages
• Get alerted before an SSL certificate expires (the three checks that actually matter)