GCP Financial Credits: The 30-Day Window and How to Hit It
August 6, 2026
Your Google Cloud bill already includes the price of the SLA. When Google breaches it, they owe you a financial credit, usually 10% to 100% of the month's charges for the affected service. The catch is the window. Every GCP SLA requires you to notify Google technical support within 30 days of becoming eligible for a credit, and eligibility is decided on a calendar month basis. If you had workloads in europe-west4-a on July 15, when a cooling failure knocked out Google Cloud VMware Engine, Bare Metal Solution and NetApp Volumes for 14 hours 55 minutes, your window is open right now and closes at the end of this month.
The window is per service, and it is short
Google's "Customer Must Request Financial Credit" clause appears in every service SLA, and it is explicit: notify Google technical support within the stated number of days "from the time Customer becomes eligible", or forfeit the credit. The countdown starts when the monthly uptime percentage is final, which for a calendar-month calculation means the end of the outage month. An incident in July makes you eligible at the end of July, so a 30-day window expires at the end of August.
| Service | Uptime commitment | Claim window |
|---|---|---|
| Compute Engine (multi-zone, Premium Tier) | 99.99% | 60 days |
| Cloud Storage (Standard, multi-region) | 99.95% | 30 days |
| BigQuery | 99.99% | 30 days |
| Cloud NAT | 99.99% | 30 days |
The "30-day window" is the general rule and the safe planning assumption. Compute Engine's SLA, revised March 2025, now allows 60 days, but Cloud Storage, BigQuery and Cloud NAT still say 30. Never trust memory here. Open the SLA page for the exact service and read the request clause before you file.
If you take one thing from this post: file within 30 days of the end of the outage month. The SLA states the credit is your sole and exclusive remedy, and missing the deadline forfeits it. There is no reminder, and no appeal.
What a credit is actually worth
Credits are a percentage of your monthly bill for the affected service in the affected region, not your total Google Cloud invoice. A 25% credit on $4,000 of Compute Engine usage is $1,000, full stop.
| Monthly uptime | Compute Engine (multi-zone) | Cloud Storage (Standard) | BigQuery | Cloud NAT |
|---|---|---|---|---|
| 99.0% to below commitment | 10% | 10% | 10% | 10% |
| 95.0% to below 99.0% | 25% | 25% | 25% | 25% |
| Below 95.0% | 100% | 50% | 50% | 50% |
Two details matter. Compute Engine is the only one of these that climbs to a full refund at the bottom tier; most GCP services cap the credit at 50% of the monthly charge for the service. And the commitment you are measured against depends on how you run things: Compute Engine's 99.99% only applies to instances spread across multiple zones. A single instance is covered at 99.9%, and a single memory-optimized instance at 99.95%.
What counts as downtime
Before you file, check the definitions, because they are narrower than you expect.
- Downtime is measured in full minutes. Every GCP SLA counts only periods of one or more consecutive minutes of downtime. Partial minutes and sub-minute blips do not count.
- Compute Engine multi-zone downtime is all-or-nothing. The SLA defines it as loss of external connectivity or persistent disk access for "all applicable running instances". If your instances run in three zones and two go down, the third keeps the service out of breach territory.
- Cloud Storage downtime is an error rate. Monthly uptime is 100% minus the average of your error rates over each five-minute period, where the error rate is 500-range responses divided by valid requests. Retries must follow the SLA's backoff rules (one second, doubling to 32 seconds), or repeated identical requests do not count toward the error rate.
- BigQuery downtime needs a 10% error rate. More than 10% of valid requests returning 500s, measured on at least 20 valid requests per period.
- Exclusions apply. Pre-GA features, factors outside Google's reasonable control, your own software or hardware, and quota limits are all carved out.
The evidence pack
The SLA text asks for one thing: "log files showing Downtime Periods and the date and time they occurred". In practice, a complete request looks like this:
- Project ID, service name and region
- Every downtime window as start and end timestamps in UTC
- Client-side logs that show the failures, with retry behavior that follows the backoff rules
- The invoice line item for the affected service, since the credit is a percentage of that figure
- A link to the matching Google Cloud Service Health incident
Claims stall when the logs don't line up with the incident you are citing. Pull the logs before you file, not after support asks.
How to file
Use the SLA credit contact form that Google links from every SLA page (support.google.com/cloud/contact/cloud_platform_sla), or open a regular Cloud support case and ask for the financial credit explicitly. Google's own billing guidance says SLA credits must be requested through a support case; they are not granted from a status page. Submit once per product per month, batching all of that product's incidents into a single request. Google applies approved credits within 60 days of the request, as a monetary credit on a future bill. Cash refunds do not exist.
Worked example: the July 2026 europe-west4-a outage
On July 15, 2026, a voltage transient at the europe-west4 data center tripped both utility feeds, the backup power system failed to take over one row, and the chiller controller dropped offline. Data hall temperatures reached 44°C and machines shut down. The incident ran from 16:57 Pacific on July 15 to 05:25 on July 16: 14 hours 55 minutes, affecting 24 VMware Engine private clouds across 20 customers, 9 Bare Metal customers and 6 NetApp clusters.
The math is straightforward. July has 44,640 minutes. Subtract 895 minutes of downtime and the monthly uptime lands at about 98.0%, which sits in the 25% band of the standard GCP schedule (check your service's SLA page for its exact tiers).
| Monthly spend on affected services | Monthly uptime | Credit tier | Credit |
|---|---|---|---|
| $2,000 | 98.0% | 25% | $500 |
| $4,000 | 98.0% | 25% | $1,000 |
| $10,000 | 98.0% | 25% | $2,500 |
Google published the incident report on July 25. If you were affected, your eligibility date is the end of July, so the 30-day window closes August 31, and Compute Engine's 60-day window closes September 30. Either way, file this month.
What happens if you miss it
The credit is forfeited. No reminder arrives, nothing is applied automatically, and the SLA's "sole and exclusive remedy" language means there is no second door. The famous exception is the April 2016 Compute Engine connectivity incident, when Google proactively granted 10% credits on GCE and 25% on VPN to all impacted customers, explicitly exceeding what the SLA promised. That happened once, nine years ago. Planning around a repeat is a bad strategy.
File this week
Start with the Service Health dashboard: note any incidents that touched your projects last month, then open the SLA page for your most expensive affected service and confirm the claim window. Pull the logs, fill in the contact form, and submit. That is the whole job, and the deadline is the only part that moves on its own.