SaaS SLAs: uptime, support and service credits explained
What a SaaS SLA promises: uptime in minutes, how downtime is defined, exclusions and service credits, with two real SLAs compared and a credit worked through.
A vendor promises “99.9% uptime”, your team depends on the product every day, and you need to know what that promise is worth when the service goes down. The answer is in the service level agreement (SLA): the part of the contract that sets a measurable commitment, such as uptime, and what the vendor owes you when it misses it.
Most SaaS SLAs promise less than the headline suggests, and pay less than an outage costs you. This guide turns uptime percentages into minutes, takes an SLA apart clause by clause, compares two published SLAs and works a service credit through. For the basics of software delivered as a service, see What is SaaS?.
An SLA in plain terms
Think of a pizza shop that promises delivery within 30 minutes or your next pizza is free. If the pizza is late, you do not get your party back. You get a voucher, and only if you ask for it, and not if the delay was caused by a snowstorm.
An SLA works the same way. The vendor commits to a number. If it misses, you can claim a service credit: extra days of service or a discount on a future bill. The credit is a small refund, not compensation for what the outage cost your business.
The parts of an SLA
Read every SLA for these seven parts:
- The commitment. Usually a monthly uptime percentage, such as 99.9%.
- The measurement window. Most measure per calendar month, so a bad day is averaged over the month.
- The definition of downtime. This decides what counts. A total outage counts everywhere; a slow or partly broken service may not.
- Exclusions. Scheduled maintenance, force majeure, your own network and third-party products are commonly excluded.
- Service credits. A table that maps uptime ranges to a credit.
- The claim process. Who must ask, how and by when. Credits are rarely automatic.
- Caps and sole remedy. A maximum credit, and often a clause that the credit is your only remedy for the outage.
Support response times are a separate commitment, sometimes in the SLA and sometimes in a support policy. Check whether they promise a first response or a fix, and for which severity levels.
What uptime means in minutes
A 30-day month has 30 x 24 x 60 = 43,200 minutes. A 365-day year has 525,600. The allowed downtime is the share of those minutes not covered by the commitment.
| Uptime commitment | Allowed downtime per 30-day month | Allowed downtime per year |
|---|---|---|
| 99% | 43,200 x 1% = 432 minutes (7.2 hours) | 5,256 minutes (87.6 hours) |
| 99.5% | 216 minutes (3.6 hours) | 2,628 minutes (43.8 hours) |
| 99.9% | 43.2 minutes | 525.6 minutes (8.76 hours) |
| 99.95% | 21.6 minutes | 262.8 minutes (4.38 hours) |
| 99.99% | 4.32 minutes | 52.56 minutes |
Each extra nine cuts allowed downtime by a factor of ten. Moving from 99.9% to 99.99% takes the monthly allowance from 43.2 minutes to under 5.
Two published SLAs compared
Two vendors publish their SLA terms in full. Their numbers are close; their mechanics differ.
| Clause | Google Workspace | Atlassian cloud |
|---|---|---|
| Commitment | 99.9% monthly uptime | 99.9% on Premium, 99.95% on Enterprise |
| Downtime means | More than a 5% user error rate | A minute with an error rate above 5% |
| Credit, below 99.9% down to 99.0% | 3 days of service added | 10% (Premium and Enterprise) |
| Credit, below 99.0% down to 95.0% | 7 days | 25% |
| Credit, below 95.0% | 15 days | 50% |
| Extra tier | None | Enterprise: 5% below 99.95% down to 99.9% |
| Claim deadline | Support case within 30 days of becoming eligible | Ticket within 15 days after the end of the month |
| Cap | 15 days of service per month | Read the full terms |
| Page date | Last modified August 31, 2026 | Effective April 30, 2026 |
Sources: Google Workspace SLA and Atlassian cloud SLA, both checked October 17, 2026. Atlassian excludes routine scheduled maintenance and reasonable emergency maintenance under its maintenance policy.
Not every vendor publishes a number. Slack’s public service level page (effective July 11, 2024) promises “commercially reasonable efforts” to keep the service available around the clock, with no percentage. Paid enterprise contracts may say more. The point stands: the SLA that binds you is the one in the contract you sign.
A credit, worked through
Example: a hypothetical team pays $12,000 a month for a SaaS product. In a 30-day month, the service is down for 2 hours.
- Downtime: 2 x 60 = 120 minutes.
- Share of the month: 120 / 43,200 = 0.28%.
- Uptime: 100% - 0.28% = 99.72%, below 99.9% and above 99.0%.
- Under tiers like Atlassian’s Premium table, assuming the credit applies to the full monthly fee: $12,000 x 10% = $1,200.
- Under tiers like Google’s: 3 days of service. At $12,000 / 30 = $400 a day, that is worth 3 x $400 = $1,200.
Now the cost of the same outage to the business. If 200 staff lose 2 hours each at a loaded cost of $50 an hour: 200 x 2 x $50 = $20,000. The credit covers $1,200 / $20,000 = 6% of it. Plan for outages with your own workarounds; the credit will not fund them.
Checklist
Before you sign, tick each line:
- The uptime percentage, measurement window and downtime definition are written down, not only on a marketing page.
- Partial outages that block your main use case count as downtime.
- Scheduled maintenance has a notice period and a cap on hours.
- You know the claim deadline, and someone owns the claim.
- Support terms state response times per severity level.
- You run your own monitoring, so you can prove the outage minutes.
- Your plan for a long outage does not depend on the credit.
For monitoring, the vendor’s status page is a start, but it reports what the vendor sees. A simple external check that signs in and loads a page every few minutes gives you your own record. Put SLA review into vendor selection, see how to evaluate SaaS solutions, and into the contract stage of enterprise SaaS deals.
Common mistakes
- Reading 99.9% as “almost never down”. It allows 43.2 minutes a month, more than 8.7 hours a year. Why it happens: the percentage looks close to 100. Instead: convert every commitment to minutes before comparing vendors.
- Missing the claim deadline. Credits are rarely automatic: 30 days at Google, 15 days after month end at Atlassian. Why it happens: nobody owns the claim during the incident. Instead: assign an owner and log outage times as they happen.
- Treating the credit as insurance. A $1,200 credit against a $20,000 loss covers 6%. Why it happens: the SLA reads like a guarantee. Instead: plan workarounds and, for critical systems, negotiate higher credits or termination rights for repeated misses.
- Ignoring the downtime definition. A slow or partly broken service may not count. Why it happens: the definition sits deep in the document. Instead: read it first, and ask how the vendor measures error rates.
Sources
- Google, Google Workspace Service Level Agreement, last modified August 31, 2026, checked October 17, 2026.
- Atlassian, Cloud service level agreement, effective April 30, 2026, checked October 17, 2026.
- Slack, Service level agreement, effective July 11, 2024, checked October 17, 2026.
In three sentences
A SaaS SLA sets a measurable commitment, usually monthly uptime, and the service credit you can claim when the vendor misses it. A 99.9% commitment still allows 43.2 minutes of downtime a month, and the downtime definition, exclusions and claim deadline decide what you can actually recover. Credits are small next to the cost of an outage, such as $1,200 against $20,000 in the example, so convert every promise to minutes, monitor it yourself and plan your own workarounds.
