GCP Financial Credits: One Claim per Product, per Month, per Region
September 6, 2026
Google's credit system is the most fragmented of the big four, and the fragmentation is procedural, not just numeric. Every product carries its own SLA with its own thresholds, credits are computed per product per region per project, and each product's claim runs on its own clock from the moment you become eligible. A multi-service outage on GCP is not one claim. It is several, filed in parallel, and treating it as one is how teams forfeit credits they had earned.
The per-product structure
Google publishes a separate SLA per product. The Compute Engine SLA covers instances and load balancing. The Google Kubernetes Engine SLA covers control planes and Autopilot pods. Cloud Build, Cloud Storage, BigQuery, and the rest each carry their own document with their own commitment and credit schedule.
| Product and shape | Commitment (standard regions) | First credit tier |
|---|---|---|
| Compute Engine, instances in multiple zones, Premium Tier | 99.99% | 10% at 99.0% to under 99.99% |
| Compute Engine, single instance, most families | 99.9% | 10% at 95.0% to under 99.90% |
| GKE regional or Autopilot control plane | 99.95% | 10% at 99.0% to under 99.95% |
| GKE zonal control plane | 99.5% | 10% at 99.0% to under 99.50% |
| Cloud Build | Per its SLA page | 10% first tier |
| GKE in Mexico and Stockholm | Lower: 99.9% regional and Autopilot | 10% at 99.0% to under 99.9% |
The per-product rule means a regional incident that degraded Compute Engine, GKE, and Cloud Build for the same hour is assessed three times, against three documents. If all three breach their own thresholds, you have three credits coming, each a percentage of that product's bill for that region and month. Filing only the Compute claim leaves the other two on the table, and Google will not cross-file for you.
The clock: eligibility, not outage
Google's standard wording: "Customer must notify Google technical support within 60 days from the time Customer becomes eligible to receive a Financial Credit." Eligibility starts when the SLA breach exists, which in practice means when the month's uptime math is knowable, not when the incident ends. Several products, Cloud Build among them, run a shorter 30-day window.
There is a subtlety worth pausing on: because credits are computed on a calendar-month basis per project per region, a brief outage late in a month may not breach the monthly threshold at all, while the same outage plus a second incident two weeks later does. The claim clock on the first incident effectively waits for the month's math. Teams that file only after obvious breaches miss the composite case: two sub-threshold incidents in one month that together cross the line. Track monthly uptime per service per region, and treat the month-end calculation as the trigger for the claim.
Eligibility starts when the breach exists, not when you notice it. On GCP the breach is a monthly number per product per region, and the filing clock is 60 days, 30 on several services, from that moment.
Assembling a multi-service claim
Google requires log files showing the Downtime Periods and the date and time they occurred, submitted through their technical support contact route. For a multi-product incident, structure the submission so each product's claim stands alone.
One claim per product. Cite the specific product SLA, the region, the project ID, and the month. Attach the log slice for that product's downtime definition: loss of external connectivity or persistent disk access for Compute instances, Kubernetes API unavailability for GKE control planes.
Respect the scope of each definition. GKE's downtime definition excludes failures of Kubernetes nodes and pods, which fall under the Compute Engine SLA instead. A cluster control plane outage claim that cites pod failures as evidence mixes scopes and invites rejection. Match each piece of evidence to the definition it supports.
Use the same incident window across claims. The provider's own incident reports anchor the timeline. Your logs should bracket the same window, in UTC, for every product claim in the set.
What disqualifies GCP claims
Four failures account for most forfeitures. Late filing, past the 60 or 30 day windows: Google's SLA language says you forfeit the right to the credit, and there is no documented appeal past forfeiture. Missing log files: the SLA requires them, and screenshots of a dashboard are not log files. Wrong scope: claiming the GKE control plane SLA for a node failure, or the multi-zone commitment for a single-instance deployment. And the region trap: filing standard-region tiers for Mexico or Stockholm workloads, where the commitments are lower by design.
The GCP 30-day window walkthrough covers the filing mechanics in detail, and the evidence checklist keeps the log files in the shape Google's reviewers expect.
UptimeAudit monitors Google Cloud's health feeds down to service and region alongside AWS, Azure, and DigitalOcean, detects when your monitored services cross a published threshold, and drafts the per-product claim set. The monitoring is the part worth imitating regardless: monthly uptime math per service per region is what turns two invisible sub-threshold incidents into one filed claim.