Google Cloud SLA uptime targets and credits. What they pay, and what to negotiate.

Google Cloud's SLAs promise a monthly uptime target and a capped credit on the affected service, never the business cost of an outage. Treat the published text as a starting position and negotiate the credit terms at every commit cycle.

What does a Google Cloud SLA actually promise?

Each Google Cloud SLA promises three things per service: a monthly uptime target, a service credit ladder that pays a percentage of that service's monthly fee when the target is missed, and a list of exclusions. It does not promise to cover what an outage costs your business.

Most production services target between 99.9 and 99.99 percent monthly uptime. The credit ladder on most services runs 10 percent, then 25 percent, then a top tier of 50 percent once availability falls below 95 percent. A few services pay up to 100 percent at that bottom tier.

The standard targets, service by service

The table below shows the published targets we see most often in enterprise reviews. The target depends on the configuration you run, so the same product can carry two or three different numbers.

Check the live SLA page for each service when you sign, and attach a dated copy to the order form. Google revises these pages, and a tier can change mid term. The Compute Engine page was last revised in March 2025, and its bottom tier now pays 100 percent below 95 percent.

How many minutes of downtime each target allows

A target reads better as minutes. In a 30 day month of 43,200 minutes, each target converts into a downtime allowance Google can use before any credit is owed. Google counts only outages of one full minute or longer, so brief errors do not add to the total.

• 99.99 percent: about 4 minutes.
• 99.95 percent: about 22 minutes.
• 99.9 percent: about 43 minutes.
• 99.5 percent (a zonal GKE control plane): 3.6 hours.
• 99 percent, where the 25 percent tier starts on most services: 7.2 hours.
• 95 percent, where the top tier starts: 36 hours.

How much do Google Cloud service credits pay after an outage?

On most services a breach earns 10 to 50 percent of the monthly fee for the affected service, and nothing for the business cost of the outage. It is applied to future use of that same service rather than paid in cash, and capped at your bill for that service in the regions that missed the target.

The SLA also states that it is your sole and exclusive remedy for a missed target. Unless your agreement adds something, the credit ladder is the whole of your recourse.

A worked example: a four hour BigQuery outage

Say your BigQuery bill is $3,000 a month and the query service is down for four hours on the day a regulatory filing is due. The arithmetic runs like this:

A few hundred dollars against a delayed filing is the typical ratio. Even at the larger bill, the credit bears no relation to penalties, lost revenue or overtime.

What you have to do to get a credit

Credits are not automatic. You claim them through Google technical support, with log files that show when each downtime period started and ended. Miss the deadline and the credit is forfeited.

• Claim window: 30 days from the moment you become eligible on Cloud Storage, BigQuery, Cloud SQL and GKE. Compute Engine and Cloud Load Balancing allow 60 days.
• Evidence: your own logs, with dates and times. Google's status dashboard is not a claim.
• Payment: applied to future bills for the covered service, within 60 days of the request.
• One basis per VM: a Compute Engine instance earns credit as a single instance or as part of a multi zone group, never both.

Is Google Cloud's 99.99 percent uptime real for your workload?

For a single service in the right topology, broadly yes, but for a whole workload it is not. A production application depends on a chain of services, and its availability is roughly the product of every link, so the composed figure always sits below the strongest single SLA on the pricing page.

Topology sets the starting number. A single zone deployment targets 99.9 percent, a multi zone regional deployment 99.99 percent, and multi region designs sit above that. The region itself stays a single point of failure for anything regional, and the marketing pages do not dwell on it.

A worked example: composing a typical service chain

Take a hypothetical customer portal. Traffic enters through Cloud Load Balancing, runs on Compute Engine across zones, reads Cloud SQL Enterprise HA and Cloud Storage, and reports through BigQuery. One batch job still runs on a single VM.

Every credit is still calculated service by service. The portal can be down for most of an hour in a month with no single SLA breached, and no credit owed at all. Real chains add more links, such as DNS, identity and messaging services, which is why the gaps we measure in client reviews run wider than this example.

Configuration details that lower the number

• Network tier: Compute Engine and load balancing drop to 99.9 percent on the Standard network tier.
• Region: in Mexico and Stockholm, the multi zone Compute Engine target is 99.95 percent.
• Edition: BigQuery Standard edition targets 99.9 percent. Cloud SQL reaches 99.99 percent only on Enterprise Plus, with HA or a read pool of at least two nodes, and that edition pays 100 percent below 95 percent.
• Uncovered setups: Cloud SQL shared core and single zone instances carry no SLA.

Which Google Cloud SLA exclusions hurt most, and how do you tighten them?

Five exclusions do most of the damage. Each one can be narrowed in the master agreement or an SLA addendum, and the request belongs on the same redline as the rates.

• Scheduled maintenance: where an SLA excludes it, as Cloud SQL does for maintenance windows, limit the exclusion to maintenance announced with reasonable notice. An unannounced window is simply an outage.
• Force majeure: the SLAs exclude errors "caused by factors outside of Google's reasonable control". Narrow that definition so failures inside Google's own infrastructure and supply chain stay covered.
• Customer configuration: outages traced to your software, hardware or setup are excluded, with Google as judge. Ask for a reasonable proof standard and written notice before the exclusion applies.
• Preview services: anything labeled Preview or pre general availability carries no SLA. Keep an inventory of production workloads that depend on preview features and review it as a standing risk.
• Third party software: Marketplace and partner services come with their own terms. Validate the SLA chain end to end, or the weakest link sets your real protection.

System quotas are a sixth exclusion that surprises teams. Errors caused by a quota applied by the system or listed in the console do not count as downtime, so confirm quota headroom for peak loads before you count on the SLA.

What Google Cloud SLA terms can an enterprise negotiate?

Enterprise customers can negotiate far more than the published text suggests, including uplifted SLAs on their most important services, named region clauses, escalating credit ladders with absolute dollar components, credits applied across the account, cash conversion at defined thresholds, and tighter carve outs. None of it is in the default text.

Why chasing a higher uptime number is the wrong fight

The usual advice is to push Google for a better percentage, 99.995 instead of 99.99. We disagree. Uptime targets are engineering commitments Google defends across its whole customer base, so the account team rarely changes them for one contract. If you do win an uplift, spend it on the one or two services your revenue depends on.

The credit mechanics are commercial terms, and Google trades those. Spend your negotiating time on what a breach pays, how fast, and against which bill.

Contract wording to ask for

1. An absolute dollar component in the credit ladder. A percentage of one service's fee stays small when that service is cheap and the workload is valuable.
2. Credits that escalate with outage duration. The default ladder measures the month, so one long outage and many short ones pay the same.
3. The right to apply credits across the account. Credit against your total commitment is usable. Credit against a single resource often is not.
4. Cash conversion above a threshold. Credit you cannot consume before the term ends has no value.
5. A named region clause. Tie the commitment to the regions you run in, with remedies if Google cannot deliver capacity or availability there.
6. A longer claim window and a frozen SLA version. Extend the 30 day window and fix the SLA text as of signature, so later edits cannot reduce your protection mid term.

What the account team will say, and what to say back

• "The SLA is standard for every customer." The published SLA is. Your agreement can add an SLA addendum that sits on top of it, and a large commitment gives you room to ask.
• "Credits are the industry norm." They are the default remedy. Ask what remedy applies when a service misses its target two months in a row.
• "Multi region architecture solves availability." It solves part of it, at a higher run rate. The contract should still pay when a regional service fails.
• "We can discuss SLAs after the commit is signed." After signature you have nothing to trade. Put SLA terms on the same redline as the rates.

The commercial context around this conversation, including commit structures and the reseller route, is covered in our partner channel strategy and our CUD negotiation tactics.

What have we seen in Google Cloud commitment reviews in 2024 and 2025?

Across roughly 25 to 35 Google Cloud commitment reviews we ran in 2024 and 2025, the published SLA almost never matched the customer's real availability exposure. Two findings came up again and again.

• The composition gap. Once we multiplied through the service chain each workload actually used, blended availability ran 0.2 to 0.6 points below the 99.99 percent headline.
• Unclaimed credits. Between 60 and 80 percent of eligible credits were never claimed, because the claim is manual and no one owned it.

A credit that no one claims inside the window is money already paid for in the contract and handed back to Google.

How the better protected customers ran it

They treated the SLA schedule as a living annex of the commercial agreement and renegotiated it with the rates. They named a claims owner. They kept a blended availability model next to the architecture diagram and updated it when the design changed.

A single review at signature does not hold up. Deployment topology changes, the service chain grows, preview dependencies build up, and Google edits the published SLA pages. Within a year the legal review is describing an architecture you no longer run.

A monthly claims routine that works

1. Export downtime events from your monitoring for every service with an SLA.
2. Match each event against that service's SLA definition of downtime and its thresholds.
3. Calculate monthly uptime per service and region, and flag any below target.
4. File each claim with Google technical support inside the window, logs attached.
5. Track credits requested against credits applied on the invoice.

When should you review Google Cloud SLA terms before a commit renewal?

Start a year out, because the SLA work depends on an architecture review that takes months. The schedule below assumes a commitment renewal date.

What to do next

1. Model your real availability. Multiply the SLAs across each production workload's service chain and compare the result with what the business was promised.
2. Name a claims owner this month. Run the correlation of outages against SLA thresholds monthly and file inside the 30 day window (60 days on Compute Engine).
3. Negotiate the credit formula. Ask for absolute dollar components, escalation with duration and credits applied across the account.
4. Tighten the carve outs in the master agreement. Maintenance, force majeure, customer fault and the third party chain.
5. Review preview dependencies at every commit cycle. Put SLA terms on the same calendar and redline as the rates.
6. Get an independent read. Our Google Cloud practice reviews SLA terms and credit claims with you before you sign.

Frequently asked questions