When did your team find out that Cloud Storage writes were failing in us-central1 on 8 October? If the answer is "when Google said so", you found out more than seven hours late. That was the first of two Google Cloud outages in two weeks, and both carry the same lesson for anyone on call.
The facts in short. A Google Cloud Storage outage in us-central1 broke writes for about 12.5 hours on 8 October 2026, and a power-related outage in europe-west2 (London) disrupted services for about eight hours on 20 October. If you run there, do not rely on the status page to detect trouble, find out which of your vendors share your region, and test regional failover before you need it.
What happened in us-central1 on 8 October?
Cloud Storage in us-central1 showed elevated write latency and write errors from 11:00 to 23:30 UTC, according to IncidentHub's analysis. Some reads were slow or failed too.
Google's preliminary report said some storage nodes had a local capacity shortfall. A traffic sorting optimisation meant to deal with it instead exhausted resources on those nodes, so the services taking in object data timed out. A separate problem in the underlying database service added metadata errors for part of the window. Google said a full root cause analysis is still under way.
Google's first status update went out at 18:24 UTC. That is more than seven hours after the start time Google later confirmed. Every update before the preliminary report listed the workaround as none.
The damage spread. Torq saw timeouts on some steps in its US region. Temporal failed over multi-region namespaces in us-central1 to replica regions as a precaution. Elastic Cloud customers saw delayed or unavailable project operations. Mixpanel's ingestion pipeline fell behind, delaying real-time data for some US projects.
Then London went down
On 20 October, ThousandEyes saw traffic to europe-west2 start failing at about 06:10 UTC. Services began to recover around 11:30 UTC, and Google declared the incident resolved at about 14:00 UTC. Google put it down to power-related issues.
The Register reported that Google's status page named the europe-west2-b zone and listed seven affected products, including Google Kubernetes Engine, Cloud Run, App Engine and Filestore. Google first said there was no workaround. Later it suggested moving workloads to another location where feasible. Nice advice, if you had already built for it.
Why is the status page always late?
Because it is a communications tool, not a monitoring tool. Someone has to confirm the problem, scope it and approve the wording. That takes time, and the provider wants to be right more than it wants to be first.
Your users do not care. Your detection has to come from your own probes: a canary that writes a small object to each bucket you depend on every minute, synthetic checks against your own endpoints from outside the provider, and alerts on error rate and latency. If those fire and the status page is green, believe your probes.
Which of your vendors share your region?
This is the question most teams cannot answer. You may have no workloads in us-central1 and still have had a bad day on 8 October, because your workflow engine, your search cluster or your analytics pipeline did.
Make a list. For every SaaS dependency in your critical path, write down which cloud and which region it runs in, and whether it has its own failover. Many vendors publish this. Ask the rest at renewal time. Then look for clusters. If five of your critical vendors and your own primary all sit in one region, you do not have redundancy. You have one region with extra invoices.
When did you last test regional failover?
Temporal's response on 8 October is the good example. It moved namespaces to replica regions before the problem got worse. That only works if the replicas exist, the data is there and someone has practised the switch.
A failover plan that has never run is a document. Run it on a quiet weekday, time it and fix what breaks. Do it again next quarter.
Two regional outages in two weeks is not proof that Google Cloud is worse than anyone else. Every provider has these days. The difference is whether you find out from your own alerts at 11:05 or from a status page at 18:24.
Quick answers
How long was the Google Cloud Storage outage on 8 October 2026?
About 12.5 hours. Writes and uploads in us-central1 failed or slowed from 11:00 to 23:30 UTC, and some reads were affected.
What caused the europe-west2 outage on 20 October 2026?
Google attributed it to power-related issues. Services in the London region were disrupted from about 06:10 UTC until Google declared the incident resolved at about 14:00 UTC.
How can SRE teams detect cloud outages before the status page?
Run your own synthetic checks against the services you depend on, such as test writes to a storage bucket every minute, and alert on error rate and latency rather than waiting for the provider.
