What an SLA service credit is worth, and why it is rarely worth much
An SLA service credit refunds part of the fee for the service that failed, not your losses. Google Workspace pays 3 to 15 days of extra service, convertible to money only for some billing arrangements. AWS pays 10 to 100 percent of one region's bill. Both call the credit your sole remedy.
- A service credit is sized against what you pay the vendor, never against what the outage cost you. Google Workspace caps it at 15 days of service in any one month.
- Whether a Google credit is money or more service depends on how you buy and how you are billed, and Google words that condition three different ways on one page.
- The credit covers the affected service only. AWS calculates it as a percentage of the monthly bill for the one service in the one region that missed.
- You have to claim it. Google gives you 30 days and says failure forfeits the right. AWS wants the claim by the end of the second billing cycle.
- Both agreements call the credit your sole and exclusive remedy, which makes the SLA a ceiling on the vendor's liability rather than a guarantee of yours.
What is an SLA service credit actually worth?
An SLA service credit is worth a fraction of one month's fee for the one service that failed, and nothing more. Google Workspace commits to a Monthly Uptime Percentage of at least 99.9% in any calendar month, then pays 3 days of service below that mark, 7 days below 99.0 percent and 15 days below 95.0 percent.
Put a working day against that ladder. A 30-day month holds 43,200 minutes. Eight hours offline is 480 of them, which reads as 98.89 percent uptime, so the outage lands in the middle band and earns 7 days of service. That is our arithmetic on Google's published bands, not a figure Google states.
Now price both sides. Take a 25-seat plan at $14 a seat as an example, so $350 a month. Seven days of service is worth about $82. The Bureau of Labor Statistics puts total employer compensation at $46.89 per hour worked for private industry workers in June 2026, so 25 people sitting idle for eight hours costs about $9,378 in payroll alone. The credit returns under one percent of it.
That ratio is the subject of this post. A service credit is sized against what you pay the vendor. Your loss is sized against what your business does in a day, and no clause in either agreement connects the two. Uptime Institute found 57 percent of respondents said their most recent major outage cost more than $100,000, and one in five reported costs above $1 million.
This post covers the credit mechanism in cloud and software agreements. The carrier side sits in your ISP SLA, what it guarantees and what it actually pays, and ticket clocks sit in first response or resolution.
What is the credit a percentage of?
The credit applies to the fee for the affected service, in the affected place, for the affected month. It is not a percentage of your bill. Amazon writes that Service Credits are calculated as a percentage of the monthly bill for Amazon EC2 in the affected AWS region, and Google caps its own aggregate credits at fifteen days of Service added to the end of Customer's term for that Covered Service.
- Service. One product missing its number credits that product, not the bundle around it.
- Place. Amazon scopes the credit to the region that missed, so a two-region business credits one.
- Month. The window is a single calendar month, so the meter resets at month end.
Google narrows the remedy further than a small base, and the form it takes depends on how you buy. The credit table awards Days of Service added to the end of the Service term (for offline billing customers), or monetary credit equal to the value of days applied to a future invoice (for online billing customers). So for a business that bought through a reseller and is invoiced in arrears, the remedy for a service it could not use is more of that service, delivered later, with no cash value at all. Read the whole page before you decide which of those you are, because Google states that condition three different ways in three places and they do not say the same thing. The table splits on offline against online billing. The non-convertibility clause says credits may not be exchanged for, or converted to, monetary amounts, except where a customer purchased online and is billed monthly, which is two conditions rather than one. The cap offers the value of 15 days of Service in the form of a monetary credit if Customer is billed monthly, which drops the purchase channel again. Ask your reseller which of the three describes your account, in writing.
Amazon reaches the same place by a different route. It will apply any Service Credits only against future payments for Amazon EC2 otherwise due from you, and states that Service Credits will not entitle you to any refund or other payment from AWS. A credit you can only spend with the vendor that failed is a discount, not compensation.
One question neither agreement answers for a small buyer. Workspace sells as a per-seat bundle at one price, while the credit is scoped to a single Covered Service. Ask your reseller which share of the seat price a single-service outage credits, and get that answer in writing.
How much downtime does each uptime band allow?
Each band allows far more downtime than it sounds like. A 30-day month holds 43,200 minutes, so the sums are short and you can verify them.
- 99.99 percent permits 4 minutes and 19 seconds of downtime.
- 99.9 percent permits 43 minutes and 12 seconds.
- 99.0 percent permits 7 hours and 12 minutes.
- 95.0 percent permits 36 hours.
Those four lines are our arithmetic on the published percentages. Read the ladders against them. Amazon commits to a Monthly Uptime Percentage of at least 99.99% for EC2 at region level and pays 10 percent of the monthly EC2 bill below 99.99 percent uptime, 30 percent of that bill below 99.0 percent and 100 percent of it below 95.0 percent. The largest band needs more than 36 hours offline inside one calendar month. A day and a half of darkness returns one month of one service's fee.
The calendar then does more work than it should. A 40-hour outage inside one month reads as 94.4 percent uptime, clears the 95 percent floor, and pays 100 percent of that month's EC2 bill. Split the same 40 hours across a month end, 20 hours either side, and each month reads 97.2 percent and pays 30 percent of that month's bill. The same outage now pays 60 percent of a monthly bill instead of 100 percent. The damage did not change. The date did.
Do you have to claim the credit, and by when?
You have to claim it in writing, inside a claim window measured in weeks. None of the agreements we read applies an availability credit automatically.
Google requires the customer to notify Google by creating a support case within thirty days from the time Customer becomes eligible to receive a Service Credit, then states the consequence in one line. Failure to comply with this requirement will forfeit Customer's right to receive a Service Credit. Amazon wants the credit request received by the end of the second billing cycle after which the incident occurred.
The vendor already holds the evidence, which is what makes the burden odd. Microsoft delivers a preliminary post-incident review within 48 hours of incident resolution, followed by a final review within five business days for broad incidents. The outage is timestamped in the vendor's own systems and written up by the vendor's own engineers, and claiming it is still your job.
Microsoft's own figures show how often this comes up. Its service description reports worldwide uptime of 99.526 percent for the quarter it labels Q1 2026, against a commitment measured monthly, per tenant and per service. Those are different measures, so treat the comparison carefully. But 0.474 percent of a 90-day quarter is about 10 hours, and 10 hours falling inside one 30-day month reads as 98.6 percent, which sits in the middle band on both ladders above.
Give the claim to a named person. Put the vendor's support path, the deadline and the words service credit in the same document as your fire drill. Document the outage on the day it happens, with the start time, the end time and the vendor's incident reference. The claim is 15 minutes of work on the day and worth nothing a quarter later.
Is the service credit your only remedy?
In both agreements we read in full, the credit is the only remedy. That one sentence converts an apparent guarantee into a cap on the vendor's liability.
Google's document states Customer's sole and exclusive remedy for any failure by Google to meet the Google Workspace SLA. Amazon's sets forth your sole and exclusive remedies, and AWS' sole and exclusive obligations. Set either sentence beside the credit ceiling and you have the vendor's maximum exposure for a catastrophic month, which is 15 days of service at Google and one month of one region's EC2 bill at Amazon.
So the document reads as a guarantee and functions as a ceiling. The uptime percentage is the part a vendor markets. The sole and exclusive remedy sentence is the part that prices it, and a buyer who reads only the first number has read the advertisement.
Expect a second ceiling in the master services agreement the SLA hangs off. A liability cap of one month of fees is routine, and we cover how to negotiate it in MSP contract red flags. Read both documents, because an SLA can look generous while the agreement around it closes the door.
An uptime percentage is the marketing number. The sole and exclusive remedy sentence is the price list.
What do the exclusions actually remove?
The exclusions remove most of the ways a working day actually breaks. Each carve-out is defensible on its own, and together they narrow the commitment to the vendor's own core platform.
Start with what counts as downtime at all. Google defines Downtime as a period in which the user web interface for a Covered Service has more than a five percent user error rate, measured based on server side error rate. A morning where one request in twenty fails is not Downtime under that definition, so the meter never records it.
Google's SLA then does not apply to any services that expressly exclude it, as stated in the documentation for such services, to any services comprised within the Google Workspace Essentials Starter edition, or to performance issues caused by factors described in the Force Majeure section of the Agreement, that resulted from Customer's equipment and/or third party equipment, not within the primary control of Google, or that followed abuses or other behaviors that violate the Agreement.
Amazon excludes unavailability caused by factors outside of our reasonable control, including any force majeure event and Internet access or related problems beyond the demarcation point, plus anything that result from any actions or inactions of you or from your equipment, software or other technology.
Microsoft draws the same line in its service description, where interruptions caused by third party service providers, or changes made within customer managed environment, aren't considered service incidents. Scheduled maintenance gets announced rather than credited, and customers are notified no later than five days in advance of all planned maintenance.
Read the pattern instead of the list. A credit exists when the vendor's own platform fails, in a way the vendor measures, for longer than the vendor's threshold, in a month you happen to notice. Your single sign-on provider, your line-of-business web app and your own change window sit outside all of it, and so do most of the failure modes in regional cloud outage assumptions.
Some vendors publish no credit schedule at all
Some products you depend on publish no uptime number and no remedy. Salesforce's published service level agreement for Slack commits only to commercially reasonable efforts to make the online Slack Services available 24 hours a day, 7 days a week, with no percentage, no credit table and no claim process in the document, which carries an effective date of 11 July 2024.
Microsoft sits at the other end and still puts the terms behind a download. The agreement governing your email uptime is not a web page. Microsoft publishes it as a Word document, with the current English edition dated October 2026. We could not open that file, so this post states no credit band for Microsoft 365, and you should download it before trusting a figure a reseller quotes.
Treat an absence as information. A vendor with no published credit schedule has promised you a level of effort rather than a level of service, and there is nothing to claim when it misses.
Read your own agreement in this order
Read five things, in this order, and stop when you have the answer to the fifth.
- Find the credit schedule and write down the percentage at each band.
- Establish what each percentage is a percentage of, by service, by site and by month.
- Check whether the credit is automatic or claimable, and note the deadline.
- Search the document for the words sole remedy and exclusive remedy.
- Open the master agreement and read the liability cap the SLA hangs off.
Then ask your provider three questions and keep the answers in writing.
- Which invoice line does this credit come off, and what is that line worth per month?
- Who on our side files the claim, and what is the deadline from the day of the outage?
- What can we recover if the credit does not cover the loss, under this contract?
The third answer decides everything. If it is nothing, the uptime commitment in your contract is a contractual measurement with a discount attached, and your continuity plan is doing all of the real work. Business interruption cover is a separate product bought separately. Negotiate the things that reduce downtime instead, which are a tested restore, a second path and a named route to escalate.
None of this makes a cloud service immune to failure, and no honest vendor claims otherwise. Reading the credit schedule buys something smaller and useful. You get a verifiable number for what a bad day returns, a named person who files the claim, and a redundancy decision made with the right figure in front of you. A business that knows its credit is worth $82 plans differently from one that assumes somebody is on the hook for the day.
FAQ
Do I have to ask for an SLA service credit, or is it automatic?
You have to ask. Google requires a support case within thirty days from the time Customer becomes eligible and states that failure to comply with this requirement will forfeit Customer's right to receive a Service Credit. Amazon wants the request received by the end of the second billing cycle. Neither applies an availability credit automatically.
What is an SLA service credit a percentage of?
The fee for the affected service, not your whole bill. Amazon calculates it as a percentage of the monthly bill for Amazon EC2 in the affected AWS region. Google pays days of service added to the end of the term for that Covered Service, capped at fifteen days in a single calendar month.
Can I get cash instead of a service credit?
It depends on how you buy and how you are billed, and Google words the condition three ways on one page. Its credit table awards days of service to offline billing customers and monetary credit equal to the value of days applied to a future invoice to online billing customers, while its non-convertibility clause carves out only customers who purchased online and is billed monthly. Amazon applies credits only against future payments and says they will not entitle you to any refund or other payment from AWS.
Is the service credit my only remedy for an outage?
In both agreements we read, yes. Google's SLA states Customer's sole and exclusive remedy for any failure by Google to meet it, and Amazon's sets forth your sole and exclusive remedies. That sentence caps the vendor's exposure at the credit, so lost revenue and idle payroll are not recoverable under the SLA itself.
How much downtime does it take to earn the biggest credit?
More than 36 hours in a single calendar month, on both ladders. A 30-day month holds 43,200 minutes, so 95 percent uptime permits 36 hours, which is our arithmetic. Below that mark Amazon pays 100 percent of the affected region's EC2 bill and Google pays 15 days of service.
Best IT MSP is the independent directory of vetted managed IT providers across the US and Canada. Organic ranking is earned on rating and verified data, and paid placement is always labelled. Take these five reading steps to three merit-ranked firms in your city and compare the answers side by side.