Uptime SLAs Explained: How to Hold Your Hosting Provider Accountable

You've seen it on every hosting provider's homepage: "99.9% uptime guarantee." It sounds reassuring — until your site goes down for three hours on a Tuesday afternoon and you discover your hosting company owes you roughly $2.73 in credits. That's when the fine print starts to matter.

This guide cuts through the marketing language and explains what uptime SLAs actually mean in practice, how to document incidents so you can claim credits, and — most importantly — how to protect yourself before you ever need to file a claim.

What Is an Uptime SLA?

An SLA (Service Level Agreement) is a formal commitment between your hosting provider and you. It defines the expected availability of their service, what happens when they fail to meet it, and any exclusions that let them off the hook.

The uptime percentage is the headline number. Here's what those percentages actually allow in terms of downtime:

Uptime Guarantee	Downtime Per Month	Downtime Per Year
99%	~7.2 hours	~3.65 days
99.9%	~43 minutes	~8.75 hours
99.95%	~21 minutes	~4.4 hours
99.99%	~4.3 minutes	~52 minutes

Most shared hosting plans sit at 99.9%. That sounds impressive until you realize 43 minutes of downtime per month is considered acceptable before any compensation kicks in.

How the Guarantee Is Measured

The measurement method matters as much as the number. Most providers measure uptime from their infrastructure perspective — not from your users' perspective. If their servers are technically responding but your DNS is broken, their internal monitors may show 100% uptime while your visitors see nothing.

This is exactly why external uptime monitoring from a third party is essential. You need your own independent record of downtime, not just the provider's word.

How Service Credits Actually Work

When a provider misses their SLA, they don't send you a check. They offer service credits — account credit toward future bills. And those credits are usually tiny.

The Typical Credit Structure

A common structure looks like this:

• 99% to 99.9% uptime achieved: 5% credit of the monthly fee
• 95% to 99% uptime achieved: 10% credit
• Below 95%: 25% credit, capped at one month's fee

If you're paying $20/month for hosting and suffer a full day of downtime, you might be entitled to a $5 credit. Meanwhile, if you're running an e-commerce store, that single day of downtime could mean thousands in lost revenue. The credit doesn't come close to covering the real cost.

Some premium providers are more generous. Liquid Web, for example, guarantees 100% network uptime and credits 10x the downtime duration — so one hour of downtime earns you 10 hours of credit. That's still not cash, but it's a significantly stronger commitment than the industry norm.

The 30-Day Claim Window

Here's a catch most people miss: you have to ask for the credit. Most providers require you to submit a written claim — typically via support ticket — within 30 days of the downtime event. If you don't, you forfeit your right to compensation entirely.

This is another reason to have independent monitoring with timestamped records. When you file a claim, you need to show exactly when the downtime started, when it ended, and what the impact was.

The Exclusions That Kill Most Claims

Here's the frustrating reality: most SLA exclusions are broad enough to cover the majority of real-world outages. Before you get excited about an SLA guarantee, read what's excluded.

Common SLA Exclusions

Scheduled maintenance: Any planned downtime announced by the provider — even if it's just a brief server restart — typically doesn't count toward your SLA calculation. Providers often schedule maintenance during off-peak hours, but "off-peak" for a US-based provider might be peak hours for your European customers.

Customer-caused issues: If your plugin conflicts with a server configuration, your traffic spike exhausts resources, or your own code causes errors, most providers will classify this as a customer-caused outage. This exclusion is often applied broadly.

Force majeure: Natural disasters, government actions, and similar unforeseeable events are standard exclusions. What's less standard — and something to watch for — is when providers classify a data center outage at a major cloud provider (AWS, Azure, Google Cloud) as "force majeure." These outages are not unforeseeable events; they're a known risk that enterprise SLAs should account for.

Third-party service failures: If your site goes down because a CDN, DNS provider, or payment gateway failed, most hosting SLAs won't cover you. Yet from your users' perspective, your site is down.

DDoS attacks: Some providers exclude downtime caused by DDoS attacks or their mitigation efforts, even though DDoS protection is often cited as a selling point.

Red Flags to Look For

When evaluating a hosting provider's SLA, watch for:

• No definition of "downtime" — if partial outages and degraded performance don't count, the bar is impossibly high
• Credits only, no exit rights — if the SLA is persistently breached, you should be able to leave without penalty
• Measurement by internal systems only — providers measuring their own uptime from their own systems are grading their own homework

How to Document Incidents for SLA Claims

You can't rely on the provider's own records to prove downtime. Here's how to build an independent, timestamped record:

Step 1: Set Up External Monitoring

Use a monitoring service like Domain Monitor that checks your site from multiple geographic locations. Make sure the service logs:

• Exact timestamp of when the outage was detected
• Duration of the outage
• Error type (HTTP status codes, DNS failures, SSL errors)
• Response times leading up to and after the incident

This gives you an auditable record that's independent of your hosting provider's systems.

Step 2: Capture Screenshots and Logs

During an outage, document what visitors are seeing — error pages, timeout messages, or server error codes. Take screenshots with timestamps. Also pull any error logs from your own server if you have access.

Step 3: Calculate the Impact

Before filing a claim, calculate the actual downtime in minutes and determine which SLA tier was breached. Check your hosting dashboard for their definition of measurement period (usually calendar month vs. rolling 30 days).

Step 4: Submit the Claim Promptly

Don't wait. File the claim as soon as the incident is resolved, and always do it in writing through the provider's official support channel so you have a paper trail.

What's Not in the SLA: What to Watch For

SLAs typically only cover uptime — not performance. Your site can be technically "up" while loading in 15 seconds, returning intermittent 503 errors, or serving a maintenance page. None of those scenarios necessarily trigger your SLA.

This is why uptime monitoring alone isn't enough. You should also track response times and SSL certificate status to catch the degraded-but-technically-up scenarios that SLAs won't cover.

When to Switch Providers

A poor SLA isn't just a financial issue — it's a signal about how a provider values reliability. Consider switching when:

1. You've experienced multiple SLA breaches in the same calendar year
2. Claims are routinely denied based on broad exclusions
3. The provider doesn't offer a path to exit without penalties when they've failed their own commitments
4. Your business has grown beyond what shared hosting can reliably support

Before switching, understand your current contract's cancellation terms. Many hosts lock you in for annual plans, and SLA credits don't typically give you an exit right — check the contract specifically for termination-for-cause clauses.

---

The bottom line: an uptime SLA is a starting point for accountability, not a safety net. Reading the fine print, maintaining your own monitoring records, and proactively filing claims when they're warranted is how you actually hold your hosting provider accountable.

For more on protecting your site's availability, see what website downtime actually costs your business and how to set up a complete uptime monitoring strategy.

Sources:

• What is an Uptime SLA Guarantee — Uptime.com
• Web Hosting SLA Comparison — FatLab Web Support
• The Future of Web Hosting SLAs — ActSupport
• Website Uptime Guarantees Explained — amazee.io

Related Articles

• VPS vs Shared Hosting - Which Is Right for Your Website?
• "Monitoring Shopify Store Uptime: What You Can and Can't Control"
• "Website Monitoring for Financial Services: Uptime When Every Second Counts"