From the Google edition of November 7, 2026
The Register: Google's root cause for the Oct. 20 europe-west-2-b outage — a PLC misconfiguration kept generators from starting while one utility feed was out for repair
The Register (reporting Google Cloud's Nov. 4 service-status incident update) · Cloud infrastructure resilience · United Kingdom (London region); applicable to multi-zone design generally
- Publisher
- The Register
- Original publication
- 2026-11-05
- Source retrieved
- 2026-11-08
- Event date
- 2026-10-20
What happened
Source finding: per Google's Nov. 4 status update as reported, an external cable fault cut feeder A while feeder B's breaker was open for repairs after an Oct. 14 generator load test; UPS units ran about five minutes, but a voltage-sensing design flaw and PLC misconfiguration meant the generator plant never received a start signal. Google reprogrammed the PLC, says it tested electrical changes, and listed two actions: automated alert-to-communication for location-impacting incidents and expanded platform-wide testing for infrastructure-level events. Vendor claim vs reporting: the root cause and remediation are Google's own account; The Register adds context on affected organizations.
Why it matters
State and local agencies and universities on Google Cloud (or SaaS hosted there) need to assume a single zone can fail during maintenance windows. Paired with the UK MoJ letter in this edition, it shows both the technical cause and a public-sector operational consequence of the same incident.
Evidence and measured results
Journalism quoting Google's published incident update; affected organizations named (Lloyds, HSBC, Royal Mail, Revolut). No independent engineering verification; no duration figures beyond the UPS five-minute ride-through.
Limitations and uncertainty
Secondary reporting of a vendor post-mortem; not an audit; UK facility; impacts on U.S. SLED customers were not reported.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-07; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agencies assume hyperscale facility redundancy prevents outages; single-zone designs remain exposed.
- Stakeholders
- Agency CIOs/CTOs
- Cloud center of excellence leads
- University research computing directors
- Risk and continuity officers
- Discovery questions
- Which critical workloads run in a single zone?
- Do you receive Google Cloud service health alerts in your incident tooling?
- When did you last test zone failover?
- Do your SaaS suppliers disclose zone/region design?
- Value hypothesis
- Interpretation: a resilience assessment could identify single-zone exposures before an incident; no savings figure is supported.
- Potential engagement
- Bounded: zone-dependency review and one failover game day for a priority Google Cloud workload.
- Unsupported claims
- That Google Cloud is less reliable than competitors
- That the fixes eliminate similar failures
- Any SLED-specific impact from this incident
Pre-sales engineering
Role takeaway
- Fit
- Directly relevant to SLED deployments on Google Cloud, including London-region academic or international workloads.
- Architecture and integration
- Regional or multi-zone deployment patterns, cross-region backups, service health integration with agency incident management.
- Prerequisites
- Workload inventory with zone placement
- Defined RTO/RPO
- Access to Cloud Service Health notifications
- Constraints
- Cost of multi-region redundancy
- Data residency limits
- Some managed services are zonal by design
- Security
- Availability; ensure failover paths keep IAM, encryption and logging controls intact.
- Proof of value
- Simulated zone-loss test with measured recovery time
- Alert-to-ticket latency measurement
- Supplier attestation of multi-zone hosting
Delivery
Role takeaway
- Work
- Map, harden and exercise zone-failure resilience for critical Google Cloud workloads.
- Dependencies
- Cloud operations team
- Application owners
- SaaS suppliers
- Ownership
- Agency cloud operations or platform engineering lead.
- Skills and adoption
- Operations staff need game-day and incident-runbook practice specific to zone loss.
- Governance checkpoints
- Architecture review for single-zone critical workloads
- Annual failover exercise
- Post-incident review of provider communications
- Acceptance criteria
- Proposed: no tier-1 workload dependent on a single zone
- Proposed: measured failover time within defined RTO
- Proposed: provider service-health alerts reach on-call within minutes
- Risks
- Cost pressure leads to single-zone designs
- Untested runbooks
- Over-trust in vendor remediation claims
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Zone-level redundancy inside a provider can be undermined by maintenance states; critical SLED workloads should use multi-zone or multi-region deployment and test failover rather than relying on facility-level power redundancy.
Governance
Who approves, reviews and stays accountable for outcomes?
Agencies can ask providers for incident post-mortems and maintenance-window risk disclosures; Google's commitment to faster automated customer communication is a vendor claim to verify in future incidents.
Security and privacy
What data, permissions and controls need testing?
Availability incident; no data compromise reported.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Limited; operations staff skills for failover exercises are the main workforce implication.
Procurement
What should contracts, pricing and exit terms secure?
Contracts and SaaS agreements can require post-mortem disclosure, zone/region redundancy and notification commitments.
Operating model
Which teams own the service once it runs?
Provider incident signals should feed agency incident management, and failover testing should be routine.
Publication history
- 2026-11-07Google · Issue 106 resources
Stable resource ID: register-google-cloud-london-europe-west2b-outage-plc-generator-root-cause-20261105