How to Detect a Cloud Provider Outage Before the Status Page Does
Tanny Kang
November 13, 2026
It's 07:10 in London on October 20, 2026. Your checkout service is throwing 5xx errors, Cloud SQL connections are timing out, and the on-call engineer is reading last night's deploy diff. Google Cloud's status page is green. It stays green for more than two hours because the real cause is a power failure in Google's europe-west2-b zone.
Direct Answer: To detect a cloud provider outage before the status page does, correlate your own errors by zone and region, check the provider's account-scoped health API, and watch third-party outage signals. If unrelated services fail at the same moment in the same zone with no deploy behind them, treat it as upstream. In the October 20 Google Cloud outage, users reported problems at 06:22 UTC, but the public status page acknowledged the incident at 08:37 UTC
Overview
- What happened in Google Cloud's europe-west2-b zone, with the timeline
- Why status pages lag behind real impact
- Six steps to detect a cloud provider outage before the status page
- How to tell your own bug from a provider outage
- What to do once you suspect the provider
- Mistakes that cost teams time during upstream outages
- Where an AI SRE fits in the first hour
- FAQ
What happened in europe-west2-b on October 20
A power failure in one London zone took down dozens of Google Cloud products, and the public status page trailed user reports by more than two hours.
Key facts (as of November 13, 2026)
- Where: europe-west2-b, one of three zones in Google Cloud's London region (StatusGator).
- Scope: Google's incident record lists 38 affected products, with impact from 06:08 to 14:00 UTC (FourWeekMBA).
- Root cause: a PLC misconfiguration meant the backup generators never started. The UPS batteries ran out while maintenance work had already reduced resilience (The Register).
- Who noticed: UK banks including Revolut and Lloyds reported disruption.
Customers in the affected zone had working signals within 14 minutes. The public status page took 2 hours 29 minutes, and the private API took 2 hours 6 minutes. Timeline sources: StatusGator and FourWeekMBA.
The Acknowledgment Gap
The Acknowledgment Gap is the time between when a provider outage starts hurting you and when the provider says so publicly. On October 20 it was 2 hours 29 minutes.
The gap isn't negligence. Providers confirm scope before they post, because a wrong status update is worse than a late one. But your SLOs don't pause while they confirm. Every minute of the gap is a minute your on-call engineer may spend debugging code that isn't broken.
Takeaway: treat the public status page as confirmation, not detection. Your detection has to come from your own signals.
How to detect a cloud provider outage before the status page
You can detect a cloud provider outage before the status page in six steps. None of them needs a new vendor, only better use of signals you already collect.
1. Tag every error metric with zone and region
If your dashboards only show service-level error rates, a zonal outage looks like a bug in every service at once. Add zone and region labels to request errors, latency and dependency calls. Then build one view that breaks errors down by zone. A single zone turning red while the others stay green is the clearest upstream signal you'll get.
2. Alert on correlated failure across unrelated services
Your own bugs usually break one service, or a chain of services that call each other. Provider outages break services that share nothing except infrastructure. Write an alert that fires when three or more unrelated services cross their error budget burn rate in the same zone within five minutes. Route it to the on-call engineer with the label "possible upstream."
3. Subscribe to the provider's account-scoped health API
On October 20, Google's private status API acknowledged the incident 23 minutes before the public page (StatusGator). Account-scoped feeds such as Google Cloud Personalized Service Health and the AWS Health Dashboard report events that touch your projects specifically. Pipe them into your alerting tool, not an email inbox nobody reads at 3 AM.
4. Watch third-party outage signals
Outage aggregators had user reports 14 minutes after impact started. Use these as triage input, not as a pager: a spike in reports for your provider, in your region, raises the odds that it's upstream. Connect the feed to your incident channel so the on-call engineer sees it next to your own graphs.
5. Run synthetic probes against managed services in each zone
A canary that runs SELECT 1 against Cloud SQL, writes a small object to storage and reads it back, once a minute per zone, tells you whether the managed service itself is healthy. When the probe fails in one zone and your code hasn't changed, you have your answer without reading a deploy diff.
6. Make "is it upstream?" the first triage question
Put it at the top of every runbook, with a time box: check the zone view, the health API and the outage signals within the first 10 minutes. Engineers default to suspecting their own code, which is usually correct. The time box stops that default from eating the first hour of a provider outage.
Is it your bug or a provider outage?
The fastest way to tell is to check whether the failure follows your code or your infrastructure.
A failure that lines up with a recent change and spreads evenly across zones is almost always yours. A failure with no change behind it, concentrated in one zone and spanning unrelated services, points to the provider. On October 20, Google also warned that customers might not be able to create new workloads (The Register), which means autoscaling and redeploys fail too. That's another sign the problem is upstream.
Takeaway: if three of these six signals point to the provider, stop debugging your code and switch to the upstream playbook.
What to do once you suspect the provider
Once you suspect an upstream outage, the job changes from fixing to containing and communicating.
- Declare the incident and set severity on customer impact. Don't wait for the provider to confirm. Severity is about your users, not about whose fault it is.
- Post a holding status update within 15 minutes. Pre-write a template: "We're seeing elevated errors affecting [feature]. We're investigating a possible issue with an infrastructure provider. Next update in 30 minutes."
- Open a support case with the provider. Include your project IDs, zone and first-error timestamp. A case on file speeds up credits and gets you into the provider's escalation path.
- Decide whether to fail over or wait it out, using the table below.
- Freeze deploys. A deploy during a provider outage adds a second variable, and new workloads may fail to schedule anyway.
Fail over when you have a tested path and the hourly cost of downtime is high. Wait when failover is untested or involves a data cutover you can't undo. The Google SRE book's chapter on managing incidents covers the roles and communication structure that keep this decision from turning into a debate in the incident channel.
What not to do during an upstream outage
Most time lost in a provider outage is lost to habits that work well for your own bugs.
- Don't wait for the status page to turn red. On October 20 that took 2 hours 29 minutes. Your own zone view had the answer in minutes.
- Don't roll back a deploy that isn't the cause. A rollback feels productive, but if nothing changed before the errors started, it adds risk and delays the real diagnosis.
- Don't page every service owner. A correlated alert that wakes up ten teams creates ten parallel investigations of the same upstream problem. Page one incident commander, and pull in owners only for failover work.
- Don't assume "multi-zone" means safe. The europe-west2-b failure still caused elevated errors across the wider region. Test what happens when a zone degrades, not only when it disappears cleanly.
- Don't skip the postmortem because it wasn't your fault. How long it took to suspect the provider, and whether your failover worked, are both your problems to fix.
Where an AI SRE fits in the first hour
An AI SRE closes the Acknowledgment Gap on your side by doing the first triage pass before a human is paged. At Vibranium Labs, that's how Tony SRE works: Tony takes the page, investigates, and hands the engineer a summary of what broke and why.
The manual first hour depends on who's on call and whether they think to suspect the provider. An AI SRE runs the same triage every time, so the upstream check happens even at 3 AM. The engineer still makes the call to fail over or wait.
The proactive part matters most after the outage. Tony flags patterns such as repeat incidents and missing runbooks, which is how a single-zone dependency turns into a fix instead of a recurring page. For a comparison of how proactive and reactive AI SREs differ, see our guide to the best AI SRE tools in 2026. For why in-house agents often miss the real root cause, see Can You Build AI SRE?. Shutterstock cut MTTR by 60% after adopting Vibranium's platform (case study).
FAQ
How do you detect a cloud provider outage before the status page?
Correlate your own errors by zone, read the provider's account-scoped health API, and watch third-party outage reports. Unrelated services failing in the same zone with no recent change is the strongest early signal. Per-zone synthetic probes against managed services confirm it.
Why are cloud status pages slow to update?
Providers confirm scope and cause before they post publicly, because a wrong update is costly. On October 20, 2026, Google Cloud's public page acknowledged the europe-west2 incident 2 hours 29 minutes after impact began.
What caused the October 2026 Google Cloud London outage?
A misconfigured PLC kept the backup generators from starting after a utility power problem in europe-west2-b. The UPS batteries ran out during a period when maintenance had already reduced resilience. Google's incident record lists 38 affected products.
Is a private provider health API faster than the public status page?
Yes, in this case by 23 minutes. Google acknowledged the October 20 incident in its account-scoped status API at 08:14 UTC and on the public page at 08:37 UTC. Subscribe to it and route events to your alerting tool.
Should you fail over during a zonal outage?
Fail over if you have a tested path and downtime costs more per hour than a failed failover would. Wait if failover is untested or requires a data cutover you can't reverse.
Can an AI SRE tell whether an outage is upstream?
An AI SRE can run the upstream check on every page, because it triages before a human is woken up. A human engineer still decides whether to fail over or wait.
