SLAs (Service Level Agreements) are the contracts between you and your infrastructure providers. Understanding them is the difference between thinking you're covered and actually being covered.
This guide breaks down uptime SLAs in plain language: what the numbers mean, what happens when providers miss them, and how to actually verify they're keeping their promises.
What is an SLA?
A Promise With Fine Print
An SLA — Service Level Agreement — is a formal commitment from a service provider about the level of reliability you can expect. In the hosting and SaaS world, the most common SLA metric is uptime percentage.
When AWS promises 99.99% uptime for EC2, or Shopify guarantees 99.98% for their platform, they're making a contractual commitment. If they fail to meet it, you're entitled to some form of compensation — usually service credits.
The key word is contractual. An SLA isn't a technical guarantee that nothing will ever go wrong. It's a business agreement about what happens when it does.
The Nines Table: Uptime Percentages Decoded
The Difference Between 99% and 99.999%
| Uptime % | Called | Downtime/Month | Downtime/Year |
|---|---|---|---|
| 99% | Two nines | 7 hours 18 min | 3.65 days |
| 99.5% | Two and a half nines | 3 hours 39 min | 1.83 days |
| 99.9% | Three nines | 43 min 50 sec | 8.77 hours |
| 99.95% | Three and a half nines | 21 min 55 sec | 4.38 hours |
| 99.99% | Four nines | 4 min 23 sec | 52.6 minutes |
| 99.999% | Five nines | 26 seconds | 5.26 minutes |
The jump from 99.9% to 99.99% looks tiny — just 0.09% — but it's the difference between 43 minutes of monthly downtime and 4 minutes. Each additional nine is exponentially harder (and more expensive) to achieve.
For most indie makers and small SaaS products, three nines (99.9%) is a realistic target. Four nines requires redundant infrastructure, automated failover, and serious engineering investment. Five nines is what banks and hospitals aim for.
What SLAs Actually Cover (And What They Don't)
Most SLAs have more exclusions than inclusions. Common exclusions:
- Scheduled maintenance — planned downtime usually doesn't count against uptime
- Force majeure — natural disasters, wars, acts of god
- Third-party failures — if your payment provider goes down, that's not covered
- Your own code — if your app crashes due to a bug, that's on you
- DDoS attacks — some providers exclude attacks from SLA calculations
- Regions or specific services — AWS SLAs are per-service, not account-wide
Read the fine print. A 99.99% SLA that excludes maintenance windows, external dependencies, and "degraded performance" might effectively be a 99.5% guarantee in practice.
SLA Credits: What You Really Get When Things Break
Here's the uncomfortable truth: SLA credits are almost never worth what the downtime cost you.
Typical SLA credit structure:
| Uptime Achieved | Credit |
|---|---|
| 99.0% – 99.9% | 10% of monthly bill |
| 95.0% – 99.0% | 25% of monthly bill |
| Below 95.0% | 50% of monthly bill |
If you pay $100/month for hosting and they have 2 hours of downtime (missing their 99.9% SLA), you get a $10 credit. If those 2 hours cost you $5,000 in lost revenue, that $10 credit is meaningless.
SLA credits are a gesture, not compensation. They incentivize providers to maintain uptime, but they don't protect your business.
That's why independent monitoring matters. You need to know when downtime happens — not just take your provider's word for it.
Don't rely on your provider to tell you when they're down. Monitor independently.
Start monitoring with PerkyDash (free plan available)How Uptime is Measured
Uptime measurement isn't as straightforward as it sounds. Key questions:
What counts as "down"?
A 500 error? Slow response (over 5 seconds)? Complete unreachability? Partial degradation? Different providers define "down" differently.
How often is it checked?
If your provider checks every 5 minutes, a 3-minute outage might never be recorded. If you check every 60 seconds, you catch more.
From where?
Your site might be down in Europe but working in the US. Does that count as 50% down or fully operational?
Who measures?
Your provider measuring their own uptime is like a student grading their own exam. Independent monitoring from multiple locations gives you the real picture.
Most providers measure from their own infrastructure, at 5-minute intervals, counting only complete outages. This is almost always more optimistic than what your users experience.
Learn more about check intervals in our Monitoring Frequency Guide.
Common SLA Tricks to Watch For
Read Before You Sign
Trick 1: Monthly vs. Annual calculation
A provider might average uptime annually. If January had 99.5% uptime (3.6 hours down) but the yearly average is 99.95%, they technically met their SLA. Monthly calculation is better for you.
Trick 2: "Degraded" vs. "Down"
Some SLAs only count complete outages. If your site loads in 30 seconds instead of 2, that's "degraded performance" — not downtime. For your users, it might as well be down.
Trick 3: Credit request windows
Many SLAs require you to request credits within 30 days. Miss the window, miss the credit. They're counting on you not tracking this.
Trick 4: Credit caps
Credits are typically capped at 50% of your monthly bill, even if downtime lasted a week. The maximum penalty is rarely proportional to the actual impact.
Trick 5: Platform vs. instance uptime
Cloud providers often measure platform availability, not individual instance availability. Your specific VM could be down while the platform reports 100% uptime.
How to Verify Your Provider's Uptime Claims
Step 1: Set up independent monitoring
Use an external monitoring service (not your own infrastructure) to check your endpoints from multiple locations every 60 seconds.
Step 2: Track response times, not just availability
A site that responds in 15 seconds is technically "up" but functionally broken for users. Monitor response time thresholds alongside uptime.
Step 3: Keep historical data
When you need to dispute an SLA, you need evidence. Store at least 12 months of monitoring history.
Step 4: Monitor from your users' perspective
Check the actual user-facing URLs, not internal health endpoints. Your /health endpoint might return 200 while your checkout is completely broken.
Step 5: Set up a status page
A status page gives you a public record of incidents. When you dispute an SLA violation, having a documented incident history strengthens your case.
PerkyDash monitors your site every 60 seconds from multiple global locations and keeps full historical data. Perfect for verifying SLA compliance.
Get started freeSLAs for Different Service Types
Hosting/Cloud (AWS, GCP, Azure)
Typically 99.95% – 99.99%. Per-service SLAs with generous exclusions. Credits are service-specific. These are generally reliable but measure platform availability, not your app's availability.
SaaS Platforms (Shopify, Stripe, Twilio)
Usually 99.9% – 99.99%. Their downtime directly impacts your business even though you can't control it. Monitor their status pages and set up alerts.
CDN (Cloudflare, Fastly)
99.9% – 99.999%. CDNs have the most aggressive SLAs because their distributed architecture makes high availability easier. Still worth monitoring independently.
DNS (Route53, Cloudflare DNS)
Typically 100% SLA. DNS failures are catastrophic since nothing works without name resolution. This is one area where five nines actually matters.
Managed Databases (RDS, PlanetScale)
99.95% is standard. Database downtime is especially painful. Always have automated backups regardless of SLA.
Worried about your infrastructure? Our downtime cost calculator shows the real financial impact.
Building Your Own SLA (For SaaS Founders)
If You're Selling SaaS, You'll Need One Too
As a SaaS founder, you'll eventually face the question: "What's your uptime guarantee?" Rules of thumb:
Conclusion
SLAs exist to set expectations, not to protect your business. The credits are symbolic. The real protection comes from:
- Monitoring independently — don't trust your provider's self-reported numbers
- Understanding exclusions — know what's actually covered
- Having an incident plan — know what to do when things go down
- Communicating transparently — status pages reduce panic and support load
The gap between your provider's SLA and your users' actual experience is where monitoring tools live. Close that gap, and you're genuinely protected — not just contractually.
Related reading: Common causes of downtime • Post-mortem template • SSL certificate monitoring
Start Verifying Your Providers' Uptime Claims Today
PerkyDash monitors from multiple global locations every 60 seconds, tracks response times, and keeps full historical data. No credit card required.
Frequently Asked Questions
What does 99.9% uptime mean?
99.9% uptime (also called "three nines") means your service can be down for up to 43 minutes and 50 seconds per month, or 8.77 hours per year, while still meeting the SLA guarantee.
What is the difference between 99.9% and 99.99% uptime?
The difference is tenfold. 99.9% allows 43 minutes of monthly downtime while 99.99% allows only 4 minutes and 23 seconds. Achieving 99.99% requires significantly more infrastructure investment including redundancy and automated failover.
What happens when a provider misses their SLA?
Most providers offer service credits, typically 10-50% of your monthly bill depending on severity. You usually need to request credits within 30 days. Credits rarely compensate for the actual business impact of downtime.
How do I verify my hosting provider's uptime?
Use an independent monitoring service that checks your site from multiple global locations every 60 seconds or less. Don't rely on your provider's self-reported uptime numbers. Keep historical monitoring data to support any SLA disputes.
Should my SaaS product have an SLA?
Yes, especially if you serve business customers. Promise slightly less than you actually deliver. Your SLA can never exceed your weakest infrastructure dependency. Pair it with a public status page for transparency.
Related Guides
Website Downtime Guide
Complete guide to downtime causes, costs, and prevention.
Downtime12 Common Causes of Downtime
Why websites go down and how to prevent each cause.
ConfigurationHow Often Should You Monitor?
The right check interval for your use case.
EmergencyMy Site is Down — Now What?
Step-by-step plan for when things go wrong.