What 99.9% uptime promises, and what you get when it is missed
The morning the mail stops, someone remembers that the SLA in the contract says 99.9% uptime. It does. The number means something specific: a ceiling on how much the service may be down before the vendor owes you anything, and a schedule of what it then owes. Both are smaller than the phrase suggests.
I have taken one such document, the Google Workspace Service Level Agreement, as the worked example, because it is public, short, and precise about days. Google's reported uptime has run far above the promise, and in two respects its terms are stricter than Microsoft's, which I will come to. The subject is the mechanism, which every vendor's SLA shares, and which the other four documents quoted below vary only in detail. Everything comes from pages I read on 12 September 2026; Google's page shows "Last modified: August 31, 2026".
99.9% is 43 minutes a month, measured monthly
The commitment is one sentence: "the Monthly Uptime Percentage will be at least 99.9% in any calendar month". A 30-day month has 43,200 minutes; 0.1% of that is 43.2. So the contract is met if the service is unavailable for 43 minutes in a month. Over a year that comes to 8.76 hours, the figure most often quoted, and it is only an illustration, because the contract never measures a year.
The monthly unit cuts both ways. A single five-hour outage in March is a breach for March, and eleven perfect months do not offset it. Eleven separate forty-minute outages in eleven months never breach. What you experience as "down again" and what the contract counts are two different bookkeeping systems.
The usual month runs far above the line, and a typical month at any of these vendors costs you minutes rather than hours. The 99.9% is what is promised, and the promise is the only part you can hold anyone to.
What you get back is days of your subscription
If the month falls below 99.9%, the SLA sets out what you receive, in a table whose heading is longer than its rows:
"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), for the applicable Covered Service(s) that did not meet the Google Workspace SLA"
- < 99.9% - >= 99.0%: 3
- < 99.0% - >= 95.0%: 7
- < 95.0%: 15
Google, Google Workspace Service Level Agreement, "Service Credit", last modified 31 August 2026
A small business pays online, which in Google's terms makes it an online billing customer: the credit, worth three days of subscription, lands on a future bill. For ten seats at whatever you pay per seat, three days is a tenth of a month's invoice. Five hours down, well past the 43-minute line, falls in the same three-day band, because the next band starts at 7.2 hours. The cap is "fifteen days of Service", half a month, and the SLA adds that credits "may not be exchanged for, or converted to, monetary amounts", apart from the future-invoice form. One more sentence caps all of the above: "This Google Workspace SLA states Customer's sole and exclusive remedy for any failure by Google to meet the Google Workspace SLA."
Microsoft's document says the same in its own currency. Its credits are 25%, 50% or 100% of the monthly fee for the same three bands, and never more than the fee. It spells out what they do not cover:
"Service Credits will not be awarded to compensate for any other forms of loss, including but not limited to lost revenue, operational costs, or any indirect losses experienced by you or the end-users."
Microsoft, Service Level Agreement for Microsoft Online Services, September 1, 2026
Put the arithmetic in plain terms. A business paying $500 a month for a service that carries $1,000 an hour of sales loses three hours of it in one outage. Three hours out of a 720-hour month is 99.58% uptime, which in Google's table earns three days of service: about $50 on a $500 subscription, against $3,000 of sales that did not happen. Nothing in the 2026 documents changes that ratio.
No claim, no credit
The credit has to be asked for, and the SLA sets a deadline for asking:
"Customer must notify Google (or, if Customer ordered Services from a Reseller, Customer must notify Customer's Reseller who must notify Google) by creating a support case within thirty days from the time Customer becomes eligible to receive a Service Credit. Failure to comply with this requirement will forfeit Customer's right to receive a Service Credit."
Google, Google Workspace Service Level Agreement, "Customer Must Request Service Credit"
Google's support help page says the same from the other side. Support will "resolve an outage tracked on the Google Workspace status dashboard and, at your specific request, send you a service credit and/or incident report". Microsoft wants the claim "by the end of the Applicable Period following the month in which the Incident occurred". It wants a description of the incident, its time and duration, the affected resources and "the number and location(s) of affected users". Leave any of that out and, in the document's words, "Failure to provide the required information will result in claims being rejected."
So the sequence is: notice the outage, establish that it crossed the line by the vendor's measure, open a case with evidence, inside a window. The predictable result is that most breaches are never compensated, not because the claim would fail but because nobody files it. For a business of eight people with nobody whose job that is, the claim never gets filed.
What counts as down is narrower than what you notice
The definition of Downtime is the sentence that decides most claims before they are filed:
""Downtime" means, for a domain, a period of time during which the user web interface for the applicable Covered Services used by Customer has more than a five percent user error rate. Downtime is measured based on server side error rate."
Google, Google Workspace Service Level Agreement, "Definitions"
Read the four conditions. It is the web interface, so mail that fails only in a phone app or through a desktop client is outside the words. The threshold is a five percent error rate: a morning in which one in twenty requests fails, or in which everything works slowly, stays inside the promise. The count comes from the server side, so what your office saw is evidence; the number comes from Google's own logs. And the exclusions remove anything "that resulted from Customer's equipment and/or third party equipment", which is where your internet provider, your DNS and your own devices live.
Other SLAs draw the same boundary differently. Microsoft excludes "performance degradation or latency issues without actual service unavailability". Its own outage notices, it warns, "are not a confirmation of missed Service Levels". Zapier's SLA excludes "third-party applications or integrations" and measures its workflow uptime by counting Zap runs, so the app on the other end of your Zap being down is not Zapier downtime. On 20 October 2025 a user on the Zapier community wrote of "multiple locations that aren't working", and the reply pointed at "Amazon Web Services (AWS) in the US-East-1 region". Everything that user ran on Zapier had stopped, and under the exclusion for third-party integrations an AWS outage may have counted as zero minutes of Zapier downtime.
Two things in Google's terms are stricter than Microsoft's, and both matter. The Workspace SLA has no carve-out for scheduled maintenance and no minimum outage length before the clock starts. Microsoft's document subtracts "Scheduled Downtime" before it measures, where a service has any; against Google's number a planned window counts in full.
Some plans have no number at all
The five vendors' standard terms, side by side:
| Vendor | Number on standard terms | Remedy | Claim window |
|---|---|---|---|
| Google Workspace | 99.9% monthly | value of 3 / 7 / 15 days of service, cap | |
| 15 | 30 days from the moment you qualify | ||
| Microsoft 365 | 99.9% monthly, per user-minute | 25% / 50% / 100% of the month's fee, cap the fee | end of the following month |
| Zapier | 99.9% monthly, only when an SLA is attached to a signed Enterprise Agreement; self-serve plans have none | 5% to 30% of monthly fees | 30 days after the month ends |
| Stripe | none; "Stripe does not warrant that User's use of the Services ... will be uninterrupted or error-free" | none stated | none |
| Slack | none since 11 July 2024: "commercially reasonable efforts"; the 2015 version promised 99.99% and 100 times the amount paid during the outage, for the Plus plan and above | none stated | none |
Zapier's SLA says on its first line what it belongs to: the Enterprise Agreement, or an Order Form that references it. It "does not apply to ... the Zapier Terms of Service", which is what a self-serve plan runs on. A business on a monthly Professional plan, the plan a ten-person business is usually on, has no uptime promise from the tool its automations run on. A day lost to troubleshooting a platform bug on that plan is a day lost: the SLA does not apply, so an uptime credit was never on the table, and any goodwill refund is at the vendor's discretion.
And Slack's row shows that the number is a page the vendor can rewrite. In 2015 the page said "99.99% monthly uptime" and "100 times the amount your workspace paid during the period Slack was down". In 2026 the same address says "commercially reasonable efforts".
Which of the tools your processes depend on carry a number, and which carry "as is"? A business can answer that from its own contracts in an afternoon. It is also the kind of thing a process audit puts in writing.
Where this leaves you
Three questions you can answer from your own contracts.
Which of your systems have a number, and which have "as is"? The answer decides whether an outage is a breach or merely an outage. For the tools with no number, the remedy is whatever you built to notice the failure, which is the subject of why automations fail silently.
What does an hour down cost you, next to three days of subscription? For most small businesses the first figure is a day's bookings or a morning's orders and the second is the price of lunch. That gap is the argument for when not to automate a process at all and for the manual fallback next to the ones you do.
Who opens the claim, with what evidence, inside 30 days? If the answer is nobody, the credit does not exist for you. A register of what is automated with a column for the vendor's status page and claim window is the cheap fix.
If you would rather have that list drawn up, with each system's number, its definition of down and what an hour of it costs your business, it is the kind of thing the process audit puts in writing. $299, three business days, and a written map you keep whether or not you hire us.
Nothing here is legal advice.
Related: what happens to your automations when the plan runs out is the other side of the same contract, the part where the limit is on you.