What happened
On June 12, 2025, Google Cloud had a genuinely global outage, not one region but every region at once. The cause was an invalid automated update to Google's quota-management policies. That bad data landed in Service Control, the component that sits in front of most Google Cloud API calls to authorize and quota-check them. Service Control lacked the validation and error handling to reject the malformed policy, so it started returning 503 errors, and because it is a global control plane, the failure replicated worldwide within seconds.
The blast radius was enormous. Dozens of Google Cloud products failed simultaneously, and because other big platforms build on top of Google Cloud, the outage surfaced as a wave of seemingly unrelated failures: Cloudflare features backed by Google Cloud degraded, Spotify errored, and a long tail of consumer and enterprise apps went with them. It was one of the clearest recent demonstrations that "the internet is down" almost always means "one provider's control plane is down."
Google identified the bad policy push, bypassed the failing quota check, and recovered most regions within about three hours. The busiest regions, notably us-central1, took longer because recovering control planes were hammered by retry storms from every client that had been failing.
SLA credit analysis (the tier and dollar logic)
Most core Google Cloud services publish strong monthly SLAs. Compute Engine commits to 99.95% for a single instance and higher for multi-zone deployments, Cloud Storage commits to 99.95% on standard tiers, and several services reach 99.99%. Those numbers set very tight downtime budgets:
- A 99.95% monthly target allows only about 22 minutes of downtime across a 30-day month.
- A 99.99% target allows only about 4.3 minutes.
The June outage delivered roughly three hours of elevated global errors. Any covered service you ran during that window almost certainly blew past its monthly target, which clears the first credit tier. Google Cloud credits are tiered against the monthly bill for the affected service, with a common schedule of a 10% credit below the SLA target, 25% below 99.0%, and 50% below 95.0%, though the exact percentages vary by product.
The dollar logic is per service. If you spent 30,000 dollars on Compute Engine last month and the outage put you in the 10% band, that is a 3,000 dollar credit on Compute Engine alone, before you add Cloud Storage, networking, or any other affected line item. Because the schedule differs by product, you check each service's own SLA rather than applying one flat rate, and none of it is automatic.
One subtlety unique to this outage is that it was a control-plane failure, not a data-plane one. Your running Compute Engine instances may have kept executing, but you could not call the APIs to create, resize, autoscale, or manage them, and many managed services returned 503s at the request level. That matters for measurement, because Google Cloud SLAs are generally scored on request success rates or error minutes, not on whether a VM was technically powered on. So when you compute your uptime, pull the actual API error data for the window rather than assuming your workloads were fine just because the servers never rebooted. The breach lives in the request-level failures, and that is exactly what the SLA measures and what a well-documented claim should show.
How to claim
- List the affected services. This was a control-plane outage, so almost everything you called through Google Cloud APIs during the window was in scope. Inventory each one.
- Pull request-level error data from Cloud Monitoring for June 12, 2025, per service and region, and compute monthly uptime for each.
- Map each service to its own SLA tier; do not assume a single percentage across products.
- Price the total in the free SLA credit calculator, then open a case per affected service through Google Cloud Support within the claim window.
The Google Cloud SLA credits overview covers the support flow, and the per-service SLA breakdown guide explains why the tiers differ between products.
Lessons
- Global does not mean safe. A single global control plane means a single global failure. Multi-region design did not help here because the fault was in the shared quota layer, not in any one region.
- Credits are per service, so a real claim is often a stack of smaller claims, not one big one. Teams that filed only for their headline service left money on the table.
- The cascade into Cloudflare and Spotify is the same dependency lesson seen in the AWS DynamoDB October 2025 outage: your resilience is only as strong as your least-independent dependency. See how it works for where this fits in claim recovery.
Track outages across providers at awsdown.com, azuredown.com, and gcpdown.com. Our sponsor Next Signal watches your cloud accounts and drafts SLA credit and billing-overcharge claims automatically, and cloud-credits.com covers credit recovery in detail.