SaaS uptime SLAs: what a 4-hour outage earns at six vendors

A 99.9% uptime promise allows about 44 minutes of downtime in a 31-day month. Miss it, and the four vendors we read that publish a figure pay back roughly 10% to 25% of one month’s fee for a full four-hour outage. Slack and Zoom publish no uptime figure at all.

That gap matters if you choose or renew a tool on the strength of its SLA. The credit is usually the only remedy the contract gives you, and it rarely covers what an outage costs. We read the current SLA documents of six vendors on October 22, 2026. Then we recomputed what each one pays for the same outage.

99.9% sounds strict but leaves room for a long afternoon off

Uptime promises are percentages of a period, so the period decides the budget. We computed the downtime each common level allows, using the minutes in each period:

Promised uptime	30-day month	31-day month	92-day quarter	Year
99.0%	432 min	446 min	1,325 min	87.6 h
99.5%	216 min	223 min	662 min	43.8 h
99.9%	43.2 min	44.6 min	132.5 min	8.8 h
99.95%	21.6 min	22.3 min	66.2 min	4.4 h
99.99%	4.3 min	4.5 min	13.2 min	53 min

The same 99.9% buys three times more slack when a vendor measures by quarter. GitHub measures each calendar quarter, so one outage of two hours stays inside its promise. The other three measure by calendar month.

Four vendors publish the terms, and each counts downtime differently

All four promise at least 99.9%, but not on every plan. Atlassian’s SLA covers only Premium and Enterprise, GitHub’s covers Enterprise Cloud, and Google’s excludes the Essentials Starter edition. The fine print differs where it decides whether you see a credit: what counts as a minute of downtime, the claim window and the credit’s value.

Vendor	Promise	Period	A minute counts as down when	Claim by
Microsoft 365 (Exchange, Teams, SharePoint)	99.9%	Calendar month	Users cannot use the service, weighted by how many users were hit	End of the following month
Google Workspace	99.9%	Calendar month	The web interface shows more than a 5% user error rate	30 days after you become eligible
Atlassian Premium / Enterprise	99.9% / 99.95%	Calendar month, in UTC	More than 5% of your requests to listed browser actions fail	15 days after month end
GitHub Enterprise Cloud	99.9%	Calendar quarter	Error rate above 5% in a minute, or unavailable per GitHub’s monitoring	30 days after quarter end

Each row comes from the vendor’s own SLA: Microsoft (October 2026 edition), Google (last modified August 31, 2026), Atlassian (effective April 30, 2026) and GitHub (version June 2026).

Microsoft’s rule is the one to read twice. Its uptime formula counts “user minutes”: each incident’s length is multiplied by “the number of users impacted by that Incident.” For Exchange Online, downtime means users “are unable to send or receive email with Outlook Web Access.”

So an outage that hits a tenth of your users for four hours counts as 24 minutes. By our calculation that leaves the month at 99.946%, above the promise, and no credit is owed.

Atlassian’s covered actions are narrow too. For Jira, its appendix lists browser actions such as View Issue and Edit Issue.

Atlassian says covered experiences are “browser-based experiences only (not, e.g., integrations, API calls or mobile versions).” If your Jira automation fails because the API is down while the web pages load, the SLA does not count it. It also states that its own “monitoring and logging infrastructure is the sole source of truth.”

One four-hour outage, recomputed across the four

We took a single full outage of four hours, every user affected, in a 31-day month (a 92-day quarter for GitHub). Then we applied each vendor’s credit table as published. The credits below are per $1,000 of monthly fees; GitHub’s credit is a share of the whole quarter’s fees, so we used $3,000 for its quarter.

Vendor	Uptime after 4 h down	Tier hit	Credit per $1,000 a month
Microsoft 365	99.462%	Below 99.9%: 25%	$250
Google Workspace	99.462%	99.0% to 99.9%: 3 days of service	$97 (3 of 31 days)
Atlassian Premium	99.462%	99.0% to 99.9%: 10%	$100
Atlassian Enterprise	99.462%	99.0% to 99.9%: 10%	$100
GitHub Enterprise Cloud	99.819% (quarter)	99.5% to 99.9%: 5%	$150

Google’s credit is days, not a percentage. Customers billed offline get days added to the end of their term. Customers billed online get “monetary credit equal to the value of days” on a future invoice. We valued 3 days as 3/31 of the month; Google does not state the formula, so treat that figure as our estimate.

Guess what an outage of one hour earns compared with four. In our run it was the same at every monthly vendor: $250 at Microsoft, about $97 at Google, $100 at Atlassian. Both outages land in the same tier, because the tables step at 99.9%, 99% and 95%. Uptime has to fall below 99% before the credit rises, which in a 31-day month means more than about 7.4 hours down.

The steps also mean Atlassian Enterprise’s tighter promise pays little extra. Its table adds a 5% tier between 99.9% and 99.95%, so an outage of 23 to 44 minutes earns something on Enterprise and nothing on Premium. From 45 minutes on, both plans pay the same 10%, 25% and 50%.

The caps and exclusions shrink the credit further

Every one of the four sets a ceiling. Microsoft’s credits “will not, under any circumstance, exceed your monthly service fees” for the service and exclude “lost revenue, operational costs, or any indirect losses.” Google caps a month’s credit at 15 days of service.

Atlassian caps it at 100% of the affected product’s invoice, gives “no refunds or cash value,” and calls credits the “exclusive remedy and Atlassian’s entire liability.” GitHub caps credits at 90 days of paid service per quarter.

Scheduled maintenance is the other carve-out. Microsoft excludes it when it gives at least five days’ notice, though its Exchange Online terms say “There is no Scheduled Downtime for this service.” GitHub has the same five-day rule, and Atlassian excludes routine and “reasonable emergency maintenance” under its maintenance policy.

Microsoft’s terms also say a credit applies only to “fees paid for the particular Service.” We found no clause in the SLA explaining how the price of a bundle such as a Microsoft 365 business plan splits between its services. Ask your reseller or Microsoft before counting on the full $250 per $1,000.

Slack and Zoom publish no number to hold them to

Slack’s current SLA page, effective July 11, 2024, is a single paragraph. Salesforce “uses commercially reasonable efforts to make the online Slack Services available 24 hours a day, 7 days a week,” except planned downtime and causes beyond its control. It names no percentage and no credit, and describes no way to claim one.

It used to promise far more. Slack’s archived January 2015 SLA guaranteed “99.99% monthly uptime” on paid plans. It promised to “refund customers on the Plus plan and above 100 times the amount your workspace paid during the period Slack was down.”

TechTarget reported in September 2019 that outages had cost Slack $8.2 million in one quarter. Per the same report, Slack then cut the multiple to 10 times and stopped paying customers an outage had not affected; it also moved to quarterly measurement. Slack’s policy archive on October 22, 2026, listed only two SLA versions, the 2015 one and the current one, so we could not read the versions in between.

Zoom’s terms of service (effective August 11, 2023) contain no uptime commitment that we could find, and its services description (effective December 1, 2025) mentions none either. The terms disclaim any promise that the services will “BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR FREE.” Large customers may have an SLA in their order form; we could not see one, and neither can a buyer on a self-serve plan.

The script we used

The recomputation is a few lines of Python. Each tier list runs from the worst level up, so the first match is the credit:

def credit(period_days, tiers, down_minutes):
    total = period_days * 24 * 60
    uptime = 100 * (1 - down_minutes / total)
    for below, share in tiers:  # worst tier first
        if uptime < below:
            return uptime, share
    return uptime, 0.0

# Microsoft 365, a 31-day month, credit as a share of the month's fee
print(credit(31, [(95, 1.00), (99, 0.50), (99.9, 0.25)], 240))
# (99.4623..., 0.25)

Two traps when you adapt it: months run 28 to 31 days and quarters 90 to 92, so pass the real length of the period that had the outage. And Atlassian measures months in UTC, so a late-evening outage on the 31st in New York counts toward the next month.

What this means for you

An SLA credit is a discount on a later invoice, not insurance. The credits above top out at a fraction of one month’s fee, while an afternoon without email or tickets can cost a small company far more. We’d weigh a vendor’s status history and how it handled its last outages above the percentage on its SLA page. We made a similar point about choosing tools in Boring tools win.

Four steps turn the terms into something you can use:

1. Put the claim windows in a calendar. Atlassian’s is 15 days after the month ends; Google’s runs 30 days from when you become eligible, GitHub’s 30 days after the quarter ends, and Microsoft’s to the end of the next month. A credit you do not claim is never paid.
2. Keep your own outage log. Note the start and end in UTC and the users and features that failed, with the error messages. Microsoft rejects claims missing “the number and location(s) of affected users,” and Atlassian names its own logs the sole source of truth, so your notes are your only record.
3. Price your outage, then compare. Multiply an hour of lost work by the people who stop, and set it against the credit per $1,000 in the table above. If the gap is large, spend on a fallback, such as a second channel for urgent messages or exports you can open offline, not on a higher plan for its SLA.
4. Ask Slack and Zoom for terms in writing before a large renewal. Without a published figure, the only promise you can enforce is one in your own order form.

If your work runs on APIs and automations, check what each SLA covers before you rely on it. Atlassian counts browser actions only, and a single cloud zone can take down far more than one tool, as Google Cloud’s London outage in October 2026 showed.

How we made this

We read the six vendors’ current SLA and terms pages, Microsoft’s October 2026 SLA document and Slack’s 2015 archived SLA on October 22, 2026. We wrote the Python script above and ran it on that date for a full outage of 1, 4, 8 and 24 hours, and for a four-hour outage hitting 10% of Microsoft 365 users; the dollar figures are per $1,000 of fees, not real invoices. We did not file a claim, and we could not see the private order forms where larger customers may have different terms.

Sources

• Microsoft, Service Level Agreements (SLA) for Online Services, October 2026 edition (Word document)
• Google, Google Workspace Service Level Agreement, last modified August 31, 2026
• Atlassian, Atlassian Service Level Agreement, effective April 30, 2026
• GitHub, GitHub Online Services SLA, version June 2026
• Slack, Service Level Agreement, effective July 11, 2024; archived SLA of January 7, 2015; policy archive
• Zoom, Terms of Service, effective August 11, 2023, and Services Description, effective December 1, 2025
• TechTarget, Slack waters down cloud SLA after $8.2 million payout, September 5, 2019
• 28creation calculation, October 22, 2026: the script above, applied to each vendor’s published credit table