Find the shared dependencies behind a cloud outage

Audit the shared path not the provider count

Provider diversity does not by itself establish independent failure paths. A service can use several regions or vendors while its runtime, identity, configuration or recovery workflow still converges on one dependency. Review the complete path needed to serve users and recover the service, not only the logos in the architecture diagram.

The June 12, 2025 Google Cloud and Cloudflare incident reports provide a useful historical case. They describe different parts of an interconnected failure, not a representative sample from which to rank providers or calculate outage probabilities. Treat their explanations as dated vendor self-reports with explicit limits. ^[1][2]

The practical question is service-specific: if this dependency is unavailable, which user functions stop, which existing functions continue and which recovery actions become impossible? A count of deployed regions cannot answer that question without the dependency relationships that connect them.

A hypothetical organization may serve traffic from two regions while both depend on the same configuration source and administrator identity path. Its serving capacity is geographically distributed, but a recovery step may still require the shared control. That is an original conceptual example, not a claim about the current architecture of either provider in the case.

AWS's static-stability guidance explains the value of continuing useful operation without depending on new provisioning or control-plane changes during a disruption. That principle helps frame the review, but it does not imply that every service can or should eliminate every shared dependency. ^[5]

The objective is a defensible dependency record: which paths are shared, what independence has actually been demonstrated and what remains an assumption. No private architecture, customer impact or live recovery exercise was inspected for this article.

Read the Google report at the trigger boundary

Google's June 2025 report attributes the incident to a policy-data change replicated globally that exposed an unhandled null-field condition in Service Control. The affected code path had been introduced earlier and was triggered by the later data condition. The report also describes recovery load and impaired monitoring or status visibility as part of the incident. ^[2]

The first lesson is about change scope, not simply deployment geography. A service can have regional components while a shared data or configuration change reaches them together. The architecture review should therefore identify which inputs are globally distributed and whether their validation and rollout boundaries match the failure domain the organization assumes.

Ask what can activate dormant behavior. A binary rollout and a later data change can be separate operational events while remaining one causal path. In the reader's system, identify which configuration, policy or schema inputs can exercise code that was not meaningfully tested by the earlier rollout. This is a review question, not an assertion that the same defect exists elsewhere.

Do not turn the incident into a generic recommendation to avoid configuration systems. Central distribution can have legitimate operational benefits. The decision is how validation, staged exposure, rollback and degraded operation account for the consequences of a bad input. The appropriate controls depend on the service and the sensitivity of what the configuration governs.

Preserve the difference between trigger, propagation and recovery. The input that starts a failure may differ from the dependency that spreads it and the resource that slows restoration. A post-incident review that records only the initial bug can miss the architecture questions that made the event broad or difficult to recover from.

The case does not establish that all globally replicated data is unsafe or that regional deployment is ineffective. It establishes a specific historical mechanism reported by the provider. Use that mechanism to ask better questions about the reader's own paths, while retaining the limits of the comparison.

Read the Cloudflare report at the dependency boundary

Cloudflare's June 12 report describes a failure involving third-party backing storage used by Workers KV, with effects on several services that consumed KV. It also distinguishes unaffected services and reports no data loss in its account of the event. These are historical provider statements, not an independent forensic conclusion or a claim about current architecture. ^[1]

The dependency question is more informative than a provider-versus-provider comparison. A component that appears internal to one vendor's product can rely on another service beneath it. A customer may not see every implementation detail, but can still review documented dependencies, failure behavior and the assurances relevant to critical user functions.

The milestone timeline uses selected UTC times from Cloudflare's report. Its narrative duration and listed start/end milestones do not agree: the narrative says two hours and twenty-eight minutes, while 17:52 to 20:28 spans two hours and thirty-six minutes. This guide preserves the reported milestones without inventing a reconciliation or plotting a definitive total duration. ^[1]

Do not combine the report's product-specific error percentages into a shared performance chart. Different products and time summaries have different denominators. A graphic that puts them on one scale without those differences would imply comparability the source does not establish.

For the reader's architecture, identify which apparently separate functions consume the same backing capability. Authentication, configuration retrieval, application data and operational interfaces can create different consequences from one dependency failure. Map the function and consequence instead of labeling the entire vendor simply available or unavailable.

Keep the historical scope visible when sharing the case. A dated dependency observation can motivate a useful review, but it should not become an undated assertion that a provider still operates the same design. The subsequent redesign matters precisely because architecture can change after an incident.

Source. Cloudflare June 12, 2025 incident report. ^[1]

Method. Selected timestamp transcription with ordinal layout. Narrative duration and listed endpoints differ; no inferred duration or provider comparison.

Accessible table and figure data

Figure 1 accessible table

UTC	Reported milestone
17:52	Initial WARP incident
18:06	Combined KV investigation
18:21	Incident escalation
19:45	Alternative KV path release
20:23	Backing storage begins recovery
20:28	Reported impact end

Figure 1 accessible table

UTC	Reported milestone
17:52	Initial WARP incident
18:06	Combined KV investigation
18:21	Incident escalation
19:45	Alternative KV path release
20:23	Backing storage begins recovery
20:28	Reported impact end

Download imageDownload table CSV

Include the subsequent redesign

Cloudflare's August 8, 2025 follow-up describes changes intended to restore redundancy across backing systems, a phased transition and a consistency issue encountered during the redesign. The report is useful because it discusses both the redundancy goal and the difficulty of changing the data path. It is still a provider's historical account, not proof of permanent immunity. ^[3]

The important tradeoff is not merely one backend versus two. A redundant storage design also has to define how writes, reads, reconciliation and consistency behave when one path is impaired. Adding another dependency can improve one failure mode while creating new operational and correctness questions.

A migration plan therefore needs its own failure analysis. The desired final architecture may be more resilient while the transition temporarily has different exposure. Ask which capabilities exist at each stage, how the team knows a stage is ready and what recovery is possible if the migration stops halfway through.

Use the follow-up to challenge simplistic before-and-after claims. An architecture diagram can show two paths immediately, while implementation, data movement and consistency validation take additional work. The reader should preserve the evidence for the actual deployed stage rather than treating the destination diagram as an accomplished state.

This does not require demanding every internal detail from a vendor. It does require understanding the documented service contract and the application's own fallback obligations. Where implementation detail is unavailable, label the relevant independence assumption and decide whether the remaining uncertainty is acceptable for the user function.

The redesign also supports a useful review habit: read incident follow-ups alongside the original report. The original mechanism explains the failure; the follow-up can explain how the provider changed its assumptions and what tradeoffs appeared during correction. Neither should be treated as a timeless reliability score.

Map serving control identity and recovery

Build a dependency ledger around critical operations. For each operation, list the serving data path, runtime configuration, identity or authorization path, monitoring path and recovery action. This is an original editorial framework. Its purpose is to expose shared dependencies that a region or vendor inventory can conceal.

The conceptual graph shows two serving paths converging on a shared dependency and a separate operator recovery path. It is not a reconstruction of Google or Cloudflare infrastructure. Each node represents a question the reader must replace with actual service evidence, and each edge represents an explicitly stated dependency rather than an inferred visual association.

For every dependency, ask what happens to existing work and new work separately. A currently running process may retain usable state while a replacement needs configuration or credentials. A recovery plan can therefore fail even when some serving capacity remains healthy. Static-stability guidance is particularly relevant to that distinction. ^[5]

Add operator access to the ledger. Which identity service, network route, console or API must be available to perform the planned correction? If the recovery action requires the same impaired dependency, the plan needs an alternative or an explicit statement that recovery waits for that dependency.

Monitoring belongs on the map too. A health signal can share a path with the service it observes, and an incident team can lose visibility while user impact continues. Identify which observations remain available under the selected scenario and who decides what to do when the preferred signal is missing.

Finally, mark evidence quality for each relationship. Distinguish documented provider behavior, observed configuration, an authorized exercise result and an untested assumption. These are not equivalent. A ledger that makes uncertainty visible is more useful than a diagram that presents every edge with the same implied confidence.

Source. Original framework informed by SRE, static-stability and recovery-planning guidance. ^[4][5][6]

Method. Conceptual dependency model, not a reconstruction of Google or Cloudflare systems.

Accessible table and figure data

Figure 2 accessible table

Path	Dependency question	Evidence needed
Serving A and B	Do both require the same runtime input?	Actual dependency inventory
Identity	Can required operators authenticate?	Authorized access evidence
Monitoring	Does observation survive the fault?	Signal path review
Recovery	Can correction run without the failed control?	Supported alternative or accepted wait

Figure 2 accessible table

Path	Dependency question	Evidence needed
Serving A and B	Do both require the same runtime input?	Actual dependency inventory
Identity	Can required operators authenticate?	Authorized access evidence
Monitoring	Does observation survive the fault?	Signal path review
Recovery	Can correction run without the failed control?	Supported alternative or accepted wait

Download imageDownload table CSV

Test the recovery load as well as failover

Recovery can create its own demand. Google's incident account describes load during restoration, and Google's SRE guidance explains how resource exhaustion and interacting dependencies can produce cascading failures. A component returning to service may face accumulated work rather than the steady-state traffic used in ordinary capacity planning. ^[2][4]

The reader's review should consider queued requests, retries, cache reconstruction and replacement startup. These are proposed workload questions, not measured effects in the reader's environment. Identify which recovery activities compete for the same dependency and whether their concurrency is bounded.

A hypothetical failover exercise that moves traffic successfully but never tests the return path leaves an important gap. The system may tolerate losing one component yet struggle when many clients reconnect or rebuild state together. Define a separate acceptance condition for recovery under the approved scenario.

Keep the test bounded and authorized. Do not turn a conceptual outage review into an unapproved load experiment. A tabletop can identify missing controls and owners; a later environment-specific exercise can measure behavior. The report should state which level of evidence exists rather than presenting the tabletop as proof of performance.

Review static capacity and provisioning requirements together. If recovery requires creating resources through an unavailable control path, extra theoretical capacity elsewhere may not help. If resources already exist, their usable state and dependencies still need verification. The goal is a recovery procedure that can operate under the failure condition it assumes.

The related retry and regional-failover guides can supply detailed mechanics without duplicating them here. This case study's contribution is the dependency question: what work arrives during recovery, what shared resource it consumes and which observation proves the service is ready for that work.

Make degradation a security decision

Incident mitigations can trade one risk for another. The historical reports include degraded or fail-open behavior in specific contexts. Those decisions must not be converted into a universal recommendation to bypass authorization or security checks when a dependency fails. The acceptable boundary depends on the protected operation and data. ^[1][2]

For the reader's service, define what degraded mode actually permits. Does it use previously validated state, deny new sensitive actions, serve a restricted subset or stop altogether? Avoid a vague availability-first label that leaves the application team to invent security behavior during the incident.

Identify the authorization guarantee that must remain true. A fallback path that preserves read-only access to non-sensitive cached content may have a different risk from one that accepts privileged changes without a required check. These are conceptual comparisons, not recommendations for a specific production service.

Any approved degradation should have an owner, scope, expiration or exit condition and observable effect. Record how the organization knows the normal control has returned and how temporary behavior is removed. A mitigation without a clear end can become an undocumented permanent security change.

Test correctness as well as reachability. An alternate path that responds quickly may still return stale, inconsistent or unauthorized results. The service owner should define which outcomes remain acceptable under the degraded contract and which require refusing the operation. Availability alone is not a sufficient acceptance criterion.

Preserve the decision in the incident record. If the team accepted a bounded security or consistency tradeoff to restore a critical function, state it plainly with the authority and subsequent checks. Do not let a successful recovery summary erase the conditions under which the service operated during the event.

Produce a service specific dependency receipt

A useful final artifact is a service-specific dependency receipt, not a generic list of cloud risks. Name the user operation, shared dependency, failure consequence, available observation, recovery action and decision owner. Attach the evidence that supports each relationship and mark assumptions that remain untested.

Google Cloud's disaster-recovery planning guidance emphasizes complete recovery processes and concrete tasks. Apply that idea to the actual service: which people, credentials, data, control paths and acceptance checks are required to execute the plan under the selected scenario? A backup or spare region is one component, not the whole process. ^[6]

The receipt should include a decision for unavailable control planes and identity paths. If the organization has an alternate, state its supported scope and last demonstrated condition. If it does not, say what recovery must wait for and whether the resulting impact is accepted. Unknown independence should not be reported as proven redundancy.

Use the historical case to prioritize one meaningful exercise. Select a critical shared path, define the scenario and required evidence, and decide which questions can be answered by read-only review before any operational test. This keeps the review actionable without turning one public outage into a mandate for a broad redesign.

The final conclusion should remain modest and useful. Multiple providers can be part of a resilient design, but independence is demonstrated through the paths that serve, observe and recover the application. Record those paths, test the important assumptions under authorization and retain the limitations. That is the durable lesson available from these dated reports, without pretending that one incident predicts every future outage.