An Uptime Promise Is a Refund Rule
A 99.9% commitment allows about 43 minutes of downtime a month. The vendor still keeps its promise inside that window. If you are comparing plans, read the credit schedule rather than the headline figure, because that is the part with money attached. The Google Workspace SLA commits to 99.9% and pays 3 days of service credit when uptime lands between 99.0% and 99.9%, as of Aug 2026.
Three days of credit is the compensation for a bad month. That figure tells you what an uptime promise is really worth, and it is rarely what buyers assume.
Turning a Percentage Into Minutes You Would Actually Notice
- ● 99.9% - about 43 min per month
- ● 99.95% - about 21 min per month
- ● 99.99% - about 4 min per month
Percentages hide the size of an outage. A 30 day month contains 43,200 minutes, so each tenth of a percent is worth about 43 minutes of allowed downtime.
The arithmetic is worth doing once and remembering. It converts marketing language into a number you can compare against your own tolerance for a quiet phone system or a dead checkout page.
| Committed uptime | Allowed downtime per 30 day month | Allowed downtime per year | Where you tend to see it |
|---|---|---|---|
| 99% | About 7 hours 12 minutes | About 3 days 15 hours | Entry tiers and tools with no formal commitment |
| 99.5% | About 3 hours 36 minutes | About 1 day 20 hours | Smaller vendors and add on services |
| 99.9% | About 43 minutes | About 8 hours 45 minutes | Google Workspace, Atlassian Premium |
| 99.95% | About 21 minutes | About 4 hours 23 minutes | Atlassian Enterprise |
| 99.99% | About 4 minutes | About 53 minutes | Top enterprise tiers, usually priced accordingly |
| 100% | None allowed | None allowed | Almost never offered without heavy exclusions |
Figures in the first three columns are arithmetic on a 30 day month and a 365 day year. The vendor commitments are taken from the Google Workspace and Atlassian service level agreements as of Aug 2026, and you should confirm current terms on the official site before signing.
The Credit Schedule Is the Part That Costs the Vendor Money
- ● Google Workspace - 3 days of service
- ● Atlassian Premium - 10% of the month
- ● Caps sit at one month of fees
Two vendors can both promise 99.9% and treat a failure very differently. The schedule underneath is where that difference lives.
Google Workspace pays in days of service. Its SLA gives 3 days of credit for uptime between 99.0% and 99.9%, 7 days between 95.0% and 99.0%, and 15 days below 95.0%, with 15 days as the maximum.
Atlassian pays in percentages of the monthly charge instead. Its Premium schedule gives a 10% credit between 99.0% and 99.9%, then 25% between 95.0% and 99.0%, and 50% below 95.0%. The Enterprise schedule adds a 5% band between 99.9% and 99.95%.
Read those two schedules side by side and the pattern appears. Even a catastrophic month returns a fraction of one month of fees, never the revenue you lost while the tool was down.
Nobody Sends You the Credit Unless You Ask
- ● Atlassian - 15 days after month end
- ● Google - 30 days from eligibility
- ● Miss it and the credit is forfeited
This is the clause that quietly voids most claims. Service credits are almost always request based, with a deadline measured from the end of the affected month.
Atlassian requires a support ticket with all fields completed within 15 days after the end of the calendar month in which the failure occurred. Google Workspace requires the request within 30 days of becoming eligible, and says the right is forfeited otherwise.
So the practical work is calendar work. If a tool has a bad month, open the claim while the outage is still fresh, because the window closes faster than most finance cycles run.
Credits also tend to arrive as money off a future invoice rather than as cash. Atlassian states that credits apply to future invoices for the affected product and cannot exceed 100% of that month’s charges.
The Exclusions Decide How Much of an Outage Counts
Downtime in an SLA is a defined term, not a plain English one. Scheduled maintenance with advance notice is normally excluded, and so are failures caused by your own network, your configuration, or third party services.
Partial degradation is the murkier case. A tool that is technically reachable but too slow to use may not register as downtime at all, since availability is often measured by whether the service responds.
That gap explains the argument that follows most outages. Your team lost a working morning, and the vendor status page recorded a shorter incident window.
What an SLA Never Covers
An SLA compensates you for the service you paid for and nothing beyond it. Lost sales, missed deadlines, and the hours your team spent working around the outage sit outside it entirely.
It also says nothing about leaving. Notice periods, auto renewal dates and export deadlines live in other clauses, and we cover that side in cancelling a contract before auto renewal.
Nor does it cover the tools that depend on this one. An outage in a payment processor or a login provider ripples through every app wired to it, and each vendor measures only its own service. You can be down for an afternoon while three separate status pages stay green.
Security posture is a separate document again. An availability commitment is not evidence of good controls, which is the ground covered by what SOC 2 compliance means for small business software.
Which Uptime Tier Fits a Small Team
Internal tools such as documents and chat: 99.9% is plenty, and paying to move up a tier rarely repays the difference. A rare 43 minute interruption is annoying rather than expensive.
Anything customers touch directly: Look for 99.95% or better and read the exclusions closely. A checkout page or a booking form loses money by the minute, and the credit will never cover it.
Phone systems and live support desks: Availability matters more than features here, so check whether the vendor publishes an SLA for that specific product rather than for the suite. Suite level promises often exclude add on services.
Early stage teams on entry plans: Assume there is no enforceable commitment at all, because most vendors reserve SLAs for higher tiers. Plan a manual fallback instead of relying on a promise you do not have.
Regulated or contractual obligations to your own clients: Match the commitment you buy to the one you give. Promising a client more uptime than your vendor promises you is a risk you are carrying personally.
Uptime Is Not the Only Number in the Agreement
Availability sits beside two other commitments that people skim past. Support response time is the first, and it often matters more day to day than a rare outage.
A vendor may promise a first response within one business day on a standard plan and within a few hours on a premium one. That gap decides how long you sit with a broken integration, and no uptime figure describes it.
Data durability is the second. Backup frequency and restore windows belong in the same contract, and a service that never goes down can still lose a week of work if its restore point is old.
Ask for all three numbers together during a trial. A vendor that answers quickly on these questions is usually the one that answers quickly during an incident.
How to Read a Vendor SLA in Ten Minutes
Start with the plan table and check which tiers the SLA covers at all. Many vendors publish an impressive figure that applies only to their enterprise plan.
Then find the measurement period, since a monthly calculation is far friendlier to you than a quarterly one. A quarterly average lets a bad week hide inside good months.
Finally look for the claim deadline and the credit cap in the same paragraph. Those two numbers tell you what a failure is worth and how long you have to collect it, which is the whole practical content of the document. It is the same close reading habit that pays off in evaluating a tool during a free trial.
The Question to Ask Before the Uptime Number Impresses You
An uptime commitment describes the vendor appetite for refunds rather than the quality of its engineering. A well run service with no SLA can beat a shaky one with a generous schedule.
Use the number as a filter and the schedule as the decision. Convert the percentage to minutes, read what a bad month pays, check the claim deadline, then ask whether your business could absorb that outage on its worst day.
If the answer is no, the fix is a fallback plan rather than a better paragraph in a contract. No credit schedule has ever brought a checkout page back online.
FAQ
How much downtime does 99.9 percent uptime allow?
About 43 minutes in a 30 day month and roughly 8 hours 45 minutes across a year. A vendor that stays inside that window has met its commitment, even if the outage landed at your busiest hour.
Do I get money back automatically when a service goes down?
No. Service credits are almost always request based with a short deadline. Atlassian requires a ticket within 15 days after the end of the affected month, and Google Workspace requires the request within 30 days of becoming eligible, as of Aug 2026.
Is a service credit the same as a refund?
Usually not. Credits are typically applied against future invoices rather than paid in cash, and they are capped. Atlassian states that credits cannot exceed 100% of the charges for the affected month.
Does an SLA cover the money I lost during the outage?
No. An SLA compensates you for the service fees only, so lost sales, missed deadlines and staff time sit outside it. That is why a fallback plan matters more than a strong credit schedule for anything customer facing.
Why does the vendor status page show a shorter outage than we experienced?
Availability is usually measured by whether the service responds, so severe slowness may not count as downtime. Scheduled maintenance announced in advance is normally excluded from the calculation as well.
Sources
- Google Workspace Service Level Agreement — checked 2026-10-01
Some links may be affiliate links. We may earn a commission at no extra cost to you.
How this article was made: it was drafted with AI assistance from the official sources listed above, and its figures were checked against those pages on the dates shown. It is not based on personal hands-on testing.
Comments
Post a Comment