SaaS Uptime SLA: What 99.9% Actually Means (And How to Calculate It)
Every SaaS promises uptime. "99.9% uptime" appears in almost every pricing page. But what does it actually allow in terms of downtime? How do you measure compliance? And what should an uptime SLA actually say?
The math: nines to downtime
| SLA | Downtime / year | Downtime / month | Downtime / week |
|---|---|---|---|
| 99% | 3 days 15.6 hrs | 7.2 hours | 1.68 hours |
| 99.5% | 1 day 19.8 hrs | 3.6 hours | 50.4 minutes |
| 99.9% | 8.7 hours | 43.8 minutes | 10.1 minutes |
| 99.95% | 4.4 hours | 21.9 minutes | 5 minutes |
| 99.99% | 52.6 minutes | 4.4 minutes | 1 minute |
| 99.999% | 5.3 minutes | 26 seconds | 6 seconds |
99.9% — "three nines" — is the standard SaaS SLA. It allows 8.7 hours of downtime per year or 43.8 minutes per month. For most B2B SaaS, this is achievable without heroic infrastructure. For payment-critical services or healthcare applications, you'd want 99.99% or higher.
99.99% — "four nines" — requires significantly more engineering: active-active multi-region deployment, automated failover, and zero-downtime deploy pipelines. The infrastructure cost is substantially higher. Very few small or mid-size SaaS companies actually achieve this.
How to calculate your actual uptime
The formula is simple:
Uptime % = (Total minutes − Downtime minutes) / Total minutes × 100
For a 30-day month: 30 × 24 × 60 = 43,200 total minutes.
If you had 15 minutes of downtime: (43,200 − 15) / 43,200 × 100 = 99.965%
The key definitional questions for your SLA:
- What counts as "downtime"? Full outage only? Degraded performance? Specific components?
- What's the measurement window? Monthly is most common. Annual is more forgiving but harder to verify.
- What monitoring method determines uptime? Your own monitoring, a third-party tool, or the customer's experience?
- Are scheduled maintenance windows excluded? Most SLAs exclude pre-announced maintenance.
PingBase's SLA tracking feature calculates uptime per monitor automatically. The monthly uptime report shows the exact percentage, total downtime duration, and individual incident contributions — the data you need to verify SLA compliance.
How SLA credits work
An SLA without a credit structure is just a promise. If you breach the SLA, what happens? The standard approach is service credits — a percentage of the monthly fee credited to the next invoice.
A typical credit table:
| Monthly uptime achieved | Service credit |
|---|---|
| 99% – 99.9% | 10% of monthly fee |
| 95% – 99% | 25% of monthly fee |
| Below 95% | 50% of monthly fee |
Credits are typically capped at one month's fee per incident or per calendar month. They're credits toward future service, not refunds. And they typically require the customer to file a claim within a set window (e.g. 30 days of the incident).
What your SLA ToS language needs to cover
If you're writing an uptime SLA for your SaaS, these are the clauses you need:
1. Definition of "downtime." Be precise. "Service is unavailable" is vague. "The production API returns 5xx errors for more than 1 consecutive minute as measured from PingBase monitoring" is specific.
2. Measurement method. Specify whose monitoring is authoritative. Using a named third-party service (PingBase, UptimeRobot) adds credibility and removes disputes about whether an incident actually occurred.
3. Exclusions. Standard exclusions: scheduled maintenance (with X hours notice), customer-caused issues, force majeure, third-party service failures (Stripe, AWS, Cloudflare), DDoS attacks.
4. Credit claim process. How does a customer request a credit? By what deadline? Credits applied to what invoice?
5. Credit limits. Maximum credits per month. Credits are not refunds. Credits cannot be exchanged for cash.
Should early-stage SaaS offer an uptime SLA?
For B2C SaaS with monthly subscriptions: no formal SLA is needed. A status page and transparent incident communication are sufficient.
For B2B SaaS with annual contracts: enterprise buyers will ask for an uptime SLA. Without one, some deals won't close. A 99.9% SLA with a reasonable credit structure is table stakes.
For regulated industries (healthcare, finance, government): SLA requirements will be specified in the RFP or procurement requirements. These often require 99.99% or higher, along with specific audit and reporting requirements.
The practical consideration: don't offer an SLA you can't measure. Before you put uptime percentages in a contract, make sure you have monitoring in place that can produce verifiable uptime reports. PingBase's monthly uptime reports give you the documented evidence if a credit claim is ever made.
Track your SLA compliance automatically
PingBase calculates uptime percentages per monitor and delivers monthly reports. The data you need to honor your SLA commitments.
Start free →