Google reports network isolation affecting portions of us-central1-b and us-central1-f, with some customers affected for four hours and eleven minutes. The scope was not every customer in those zones.
Google Cloud · inspect the source ↗INCIDENT BRIEF / SERVICE OUTAGE
Google Cloud’s Iowa isolation: test the failure domain, not the zone label
A regional network incident raises a practical buying question: do your recovery plans depend on infrastructure that can fail together? Read Google’s account and use the lessons to challenge assumptions about isolation and recovery.
01 / SOURCE-ATTRIBUTED REPORTING
What the evidence establishes.
The provider attributes the event to a physical fiber disconnection during maintenance.
Google Cloud · inspect the source ↗A September 29 addendum expands the impact account to regional services with dependencies on the affected datacenter.
Google Cloud · inspect the source ↗02 / KEEP THE SEQUENCE
A dated record.
Network isolation
The provider dates the disruption to September 1 in US/Pacific time.
Source reference ↗Impact account extended
An addendum adds context about regional services that depended on the affected datacenter.
Source reference ↗
Dates and time zones follow the cited report where specified. A report date is distinct from the incident date and from our review.
03 / GOVERNATLAS EDITORIAL ANALYSIS
Make the lesson useful.
These are proposed review and trial activities inspired by the reported event. They are not completed tests or claims that a particular control guarantees prevention.
Ask what can fail together.
Two resources carrying different labels do not by themselves establish independent recovery paths. In your own architecture review, trace network, control-plane, identity and operational dependencies across the proposed standby environment. The useful output is a dependency map that identifies assumptions and the evidence still needed to test them.
BRING THIS INTO YOUR REVIEW
Build a vendor exit and continuity record ↗Ask the supplier to walk one representative workload through loss of its primary location. Record which dependencies remain shared, who restores each one and what evidence would show the recovery target was met.
Treat the incident report as a versioned record.
An initial report may describe the immediately visible failure while later updates explain dependent services. Preserve the version used for a purchasing decision and revisit the conclusion when scope changes. An absence from an early impact list should become a follow-up question rather than a promise of immunity.
BRING THIS INTO YOUR REVIEW
Evaluate data observability evidence ↗Compare the initial report and the addendum against your service inventory. Mark confirmed dependencies, open questions and the next review owner.
FROM READING TO A REVIEW YOU CAN OWN
What will you examine next?
A reported failure is a reason to ask a precise question about your own service. It does not establish that your configuration shares the same weakness. Start with the workflow, deployment and dependencies you can identify, then decide which proposed activity is relevant.
For each relevant lesson, name an accountable role, describe the evidence you would request and define an authorized trial before performing it. Keep “not checked” distinct from a recorded observation. If a check reveals a gap, retain its scope and next action rather than converting the observation into a supplier-wide verdict.
Use this portable record in a review, renewal discussion or continuity exercise. A material configuration change, a revised incident account or the completion of an action can trigger your next review. Your entries remain your working notes; publication evidence and your own acceptance decision are separate records.
Use non-sensitive roles and evidence references. Entries stay in this open page and reset on reload; download before leaving. This tool performs no tests and produces no readiness score.
2 unassigned owners · 2 activities not checked
Define a safe, measurable rehearsal
Record the normal result before changing anything. Agree an authorized test boundary, an observable stop condition and who can stop the exercise. Check restored configuration and unfinished work separately. These entries are your plan, not permission to test a service.
04 / LEAVE UNCERTAINTY VISIBLE
What this record does not establish.
This is the provider’s account, not an independently reproduced test or a complete customer impact census.
The page’s headline and detailed report give different start minutes. This brief uses day-level dating and does not resolve that discrepancy.
Geography: Google names Iowa (us-central1). The marker represents the approximate region, not a datacenter or the full affected footprint.
05 / THE EVIDENCE RECORD
Sources & editorial review.
Google Cloud us-central1 network isolation, September 2026 ↗
Google Cloud · captured 2026-10-16 (UTC)
Inspect preserved provenance
- Source
- f1bc411f-e023-4c0f-9d38-1eb72241f5ee
- Observation
- 11a25922-8df9-4985-906e-5d96d9dd59d6
- SHA-256
- 9dad5ad4d9f19d10fed663a7a0a3b6f0bcebc426797eb2ddf0c7db5b7ea8010a
Reporting and proposed methods by GovernAtlas editorial. Published review: 2026-10-17 (UTC). Revision 1. Preserved source bytes identify the material reviewed; they do not independently verify the provider’s account.
Submit a correction with supporting evidence ↗