Skip to main content
gcpdown
criticalCloud IAMGlobal

The June 2025 Google Cloud Global Outage: How Service Control Crash-Looped

GCPDown Research · Incident analysisPublished June 16, 2025Updated June 20, 20269 min read

Timeline

  1. Impact begins

    A newly-inserted quota policy change with unintended blank fields is read by Service Control. The affected code path hits a null pointer and the binary begins crash-looping, causing external API requests across Google Cloud to return 503 errors globally.

  2. Investigating

    Google acknowledges elevated error rates across multiple Google Cloud products and identifies the API-serving layer as the common factor rather than any individual product.

  3. Identified

    Root cause identified in Service Control’s handling of the policy change. Engineers develop a fix and bypass the offending code path (the "red-button" mitigation).

  4. Mitigating

    The mitigation is rolling out. Most regions recover within minutes, but us-central1’s Service Control tasks are overwhelmed by a retry herd as every client reconnects at once.

  5. Resolved

    Service Control is healthy in all regions and API error rates return to baseline. Dependent products and downstream services drain their backlogs.

Root cause

Google Cloud, like the other hyperscalers, runs a shared layer that sits in front of nearly every API call - Service Control, which enforces quota and checks policy before a request reaches the product behind it. On June 12, a change to quota-policy data was inserted that contained unintended blank fields. When Service Control read that data, it exercised a code path with a null-pointer defect - and, critically, that path was not protected by a feature flag, so there was no gradual rollout to catch the crash before it went global. Service Control began crash-looping in every region at once.

Two properties made this a global event rather than a contained one. First, Service Control is in the request path for almost everything, so its failure isn't a degraded product - it's a 503 on the front door of the whole platform. Second, the missing feature flag meant the bad data reached every region simultaneously; a staged rollout would have failed one region and been rolled back.

Business impact

The blast radius was enormous and shallow: dozens of Google Cloud products returned errors while the products themselves were fundamentally healthy - they simply couldn't be reached through the API layer. The visible casualties told the story of how much of the internet sits on Google Cloud: Cloudflare's Workers KV (which depended on Google Cloud), Spotify, and Discord all degraded during the window. For individual customers, anything that made Google Cloud API calls on its hot path - which is to say almost everything - saw errors until Service Control recovered.

The recovery also demonstrated the retry herd problem: when the mitigation landed, every client that had been failing for an hour reconnected at once, and us-central1's Service Control tasks - the largest fleet - buckled under the reconnection storm and took longest to stabilize.

Prevention and lessons

  1. Feature-flag every code path that reads external data. The defect existed for a while harmlessly; the outage happened because the triggering data reached it globally with no staged rollout. Flags that fail one region first are the single highest-leverage safety control.
  2. Design for control-plane independence. Workloads that cached credentials and results, and that didn't call the API server on every request, degraded less. The GKE high availability guide covers keeping your data plane serving when the control/API plane is down - the defining resilience skill for GCP.
  3. Bound your retries. The us-central1 tail was a self-inflicted retry herd. Exponential backoff with jitter protects both you and the recovering shared service.
  4. Know your global dependencies. "We're multi-region" is no defense against a global-layer failure. Map which global products (Service Control, Cloud Load Balancing, Cloud DNS) your architecture depends on - see multi-region GCP patterns.

SLA credit eligibility

Yes for many affected workloads - API unavailability counts against product SLOs. Roughly 3 hours of full unavailability approaches the 99.99% monthly threshold for regional Compute Engine; claimable at the 10% tier with evidence. GCP caps credits at 50% and requires notice within 30 days.

Work out what your bill was owed with the independent Google Cloud SLA credit calculator, or automate breach detection with Next Signal (sponsor). For the full claim process, see the Google Cloud credit-recovery playbook.

Questions about this outage

What caused the June 12, 2025 Google Cloud outage?

A quota-policy update containing unintended blank fields was read by Service Control, Google Cloud’s global API-management layer. The code path handling it had a null-pointer defect and lacked feature-flag protection, so Service Control crash-looped globally and returned 503 errors on API requests across dozens of Google Cloud products.

How long did the June 2025 Google Cloud outage last?

About three hours globally (roughly 17:50 to 21:00 UTC on June 12, 2025). Most regions recovered within an hour of the mitigation; us-central1 took longest because a retry herd overwhelmed the recovering Service Control tasks.

Why did one component take down so many Google Cloud products?

Service Control checks quota and policy on nearly every external Google Cloud API call. It is a shared global dependency, so when it failed, every product that serves an API through it - and the third parties built on them, including Cloudflare Workers KV, Spotify, and Discord - failed together.

Did the June 2025 outage qualify for SLA credits?

For workloads that were unavailable, ~3 hours of impact in the month can breach the relevant product SLOs, putting customers in the 10% credit tier where they could evidence it. Google requires notice within 30 days - the tightest window of the major providers.

Next time, hear it from us first

Instant alerts when Google Cloud incidents are detected - services and regions included.

Get outage alerts

More post-mortems

Cloud Load Balancing

The November 2021 Google Cloud Load Balancer Outage: A Config Race Condition

A race condition in the pipeline that propagates Google Cloud Load Balancer configuration caused a corrupt configuration to be pushed globally. Requests to sites fronted by GCLB began returning 404 errors even though the backends were healthy - taking down high-profile sites for roughly two hours until the configuration was rolled back.

Virtual Private Cloud

The June 2019 Google Cloud Network Congestion Event

A routine maintenance configuration change was applied to a far wider scope than intended, descheduling the network control-plane jobs in several US regions. The network fell back to preserving only high-priority traffic (like the control plane’s own signaling) while starving everything else, so Compute Engine, YouTube, Gmail, and Snapchat degraded severely for about four hours - worst in the US East.

Cloud Storage

The March 2019 Google Cloud Storage Outage: An Internal Blob Failure

Degradation in an internal blob-storage service that underpins Google Cloud Storage caused elevated error rates and latency for GCS operations, and for Google’s own products that store objects on the same layer - Gmail and Photos attachments among them - for roughly four hours.