SLA and uptime guarantees — what 99.9% actually means
8 min read
Why uptime percentages matter more than they sound
Hosting providers love to advertise “99.9% uptime” or “99.99% uptime” as if the difference is tiny. In reality, those extra 9s often translate into very different expectations, incident frequency, and operational maturity.
An SLA (Service Level Agreement) is the contract language that defines what uptime the provider commits to, how it’s measured, and what you receive if they fail to meet it. For beginners, the key is to understand:
- What the uptime percentage actually allows in downtime
- What the SLA counts as downtime (and what it excludes)
- Whether you get a service credit or an actual refund
- How to monitor uptime independently (don’t rely solely on provider status pages)
Decoding “99.9%” and “99.99%” into real downtime
Uptime is a percentage of time your service is available during a measurement period (often monthly). Downtime is what’s left over.
Common uptime tiers and their downtime budgets
Below are approximate maximum downtime allowances if an SLA is measured over a month, year, etc. (Exact numbers vary slightly depending on the length of the month and the provider’s calculation method.)
#### 99.9% (“three nines”)
- Per month: ~43 minutes 12 seconds
- Per year: ~8 hours 45 minutes 36 seconds
- Per month: ~4 minutes 19 seconds
- Per year: ~52 minutes 33 seconds
- Per month: ~26 seconds
- Per year: ~5 minutes 15 seconds
Practical interpretation: why one extra 9 is a big deal
Going from 99.9% to 99.99% reduces allowable downtime by about 10x. That usually implies:
- More redundancy (network, power, storage, compute)
- Faster incident response
- Better monitoring and automated failover
- Tighter maintenance practices
A concrete example
If your provider offers 99.9% monthly uptime and you experience:
- 20 minutes outage on a Tuesday
- 30 minutes outage during a weekend deploy gone wrong
That month’s uptime is roughly below 99.9% (because the allowance is ~43 minutes). If the SLA is strict and you can prove it qualifies, you may be eligible for compensation—usually in the form of a credit.
What an SLA typically measures (and how)
Not all “uptime” is measured the same way. Read the SLA definitions carefully.
Common SLA measurement methods
- Service availability at the network edge: “Is the VM reachable (ping), is the port open?”
- Service availability at the application level: “Does HTTP return a valid response?”
- Platform availability: “Is the managed database responding to queries?”
Measurement period: monthly vs annual
Most hosting SLAs are monthly, meaning each month is evaluated independently. That matters because:
- A single bad month may qualify for credits, even if the rest of the year is perfect.
- Annual marketing claims can hide “one terrible month” behind eleven good ones.
Rounding, minimum outage duration, and “incident granularity”
Many SLAs include details like:
- Minimum downtime event length: e.g., “Downtime must be at least 5 minutes to count.”
- Sampling intervals: e.g., “Measured in 1-minute intervals.”
- Aggregation rules: brief flaps might be ignored or averaged.
What SLAs commonly cover
Think of SLAs as covering the provider’s responsibility for the infrastructure they control. Common covered components include:
Network and datacenter basics
- Power redundancy and power availability
- Core networking (switches/routers)
- Provider’s upstream connectivity
- Physical host availability (for VPS/cloud compute)
Managed services (when explicitly stated)
For managed databases, load balancers, Kubernetes control planes, etc., the SLA may cover:- API availability
- Service endpoint responsiveness
- Cluster control-plane uptime (not necessarily your workloads)
Example SLA wording (typical)
- “We guarantee 99.99% monthly uptime for the Load Balancer service.”
What SLAs often exclude (the “gotchas”)
This is where beginners get surprised. Most SLAs exclude many real-world downtime causes.
Planned maintenance windows
Providers often exclude downtime due to:- Scheduled maintenance (sometimes with notice)
- Emergency maintenance (sometimes without notice)
Customer-caused issues
Common exclusions:- Misconfiguration (firewall rules, security groups, DNS changes)
- Overloaded instance due to insufficient sizing
- Application crashes, memory leaks
- Unpatched software leading to compromise
- Account suspension due to policy violations or billing issues
Third-party dependencies
Often excluded:- DNS providers (if not the host’s DNS)
- CDN outages (if external)
- Payment processor issues
- Your upstream API providers
Force majeure / events beyond control
Examples:- Natural disasters
- Widespread internet routing incidents
- DDoS beyond stated mitigation capacity (unless explicitly covered)
“Performance” vs “uptime”
Your site can be “up” but unusably slow. Many SLAs measure only availability, not latency. If you care about performance, look for:- Latency SLOs (service level objectives)
- Response time commitments
- Packet loss/jitter thresholds (rare in basic hosting SLAs)
Credit vs refund: what you actually get when they miss the SLA
Most SLAs do not promise to “refund your losses.” They typically offer service credits.
Service credit (most common)
A service credit is usually:- A percentage of your monthly fee credited to your account
- Applicable only to the affected service
- Not cash
- Sometimes must be used within a certain time
- If uptime falls below 99.9% → 10% credit
- Below 99.0% → 25% credit
- Below 95.0% → 50% credit
Refund (less common)
A refund is money back to your payment method. True refunds are rarer and often limited to:- First month satisfaction guarantees
- Clear billing mistakes
- Specific consumer protection regions
Important: you often must request the credit
Many SLAs require that you:- Open a support ticket within X days (often 7–30 days)
- Provide logs or monitoring evidence
- Specify affected resources, timestamps, and impact
How to monitor uptime (so you can verify SLA claims)
Independent monitoring is essential. Provider status pages are useful, but they’re not evidence and may not reflect your specific outage.
What to monitor (beginner-friendly checklist)
#### External checks (from outside the provider)
- HTTP/HTTPS check to your site’s key endpoints
- TCP port checks (e.g., 443, 22 if appropriate)
- DNS resolution checks (especially if you manage DNS elsewhere)
- Instance health (CPU, memory, disk space)
- Application process health
- Database connectivity
- Error rates (5xx responses)
- Latency and throughput
Practical example: basic HTTP uptime monitoring
You can monitor a URL like:- `https://example.com/health`
A better health endpoint validates critical dependencies:
- database connection (read-only ping)
- cache connectivity
- queue access (optional)
Choose monitoring locations wisely
If you only monitor from one region, you can miss partial outages.Good practice:
- Monitor from at least 2–3 geographic regions
- Use both IPv4 and IPv6 if your audience does
- Track latency as well as up/down
Alerting and evidence for SLA claims
For SLA disputes, you want:- Timestamps (UTC is best)
- Duration of failure
- Type of failure (timeout, 5xx, DNS failure)
- Screenshots or exported incident reports
- Correlation with provider announcements (if any)
Reading SLA language like a pro (quick tips)
Look for the exact definition of “downtime”
Questions to answer:- Is downtime “packet loss” or “unable to establish TCP connection”?
- Does HTTP 500 count as uptime or downtime?
- Are partial outages included?
Identify the scope: what service is covered?
A datacenter SLA might not cover your VM. A VM SLA might not cover managed backups. A load balancer SLA might not cover your instances.Check exclusions and notice requirements
- How much planned maintenance notice is required?
- Are there “emergency maintenance” carve-outs?
- Are DDoS events excluded?
Confirm the compensation method and maximum payout
Even if they miss uptime badly, the SLA might cap credits at:- 10% of monthly bill
- 1 day of service
- the affected component only
Setting expectations: what you should do as a beginner
An SLA is not a substitute for architecture. If uptime matters to you, consider:
- Backups (and test restores)
- Redundancy: multi-zone or multi-region setups when justified
- Failover plans: DNS failover, standby instances, replicated databases
- Runbooks: steps to recover when things break
- Monitoring: external + internal checks
Summary: what “99.9%” really means in decision-making
- 99.9% uptime can still mean ~43 minutes of downtime per month.
- 99.99% uptime shrinks that to ~4 minutes per month, often indicating stronger infrastructure and operations.
- SLAs usually cover provider-controlled components and exclude maintenance, customer errors, and many external events.
- Compensation is typically service credits, not refunds—and you often must request them with evidence.
- The best defense is independent monitoring plus good operational basics (backups, redundancy, recovery plans).