How to Read a Web Hosting Provider’s SLA

Your hosting provider promises “99.9% uptime.” Sounds good. What does it actually mean? If your site is down for 8 hours, do you get a refund? Probably not. Let me show you how to read a hosting SLA so you know what is really guaranteed, what is just marketing, and what to do when they fail to deliver.

The SLA (Service Level Agreement) is a contract. Most people sign up without reading it. Then they are surprised when outages happen and no refund shows up. This guide is how to read one before you sign up, and what to watch out for.

What an SLA Is (And What It Is Not)

What it is: A contractual commitment from the provider about service availability, performance, and remedies when those are not met.

What it is not: A guarantee that your site will be online. It is a promise about specific things, with specific exclusions, with specific remedies that are often trivial.

The trick is that the marketing page says “99.9% uptime guaranteed!” The SLA says “we guarantee 99.9% monthly uptime excluding scheduled maintenance, force majeure, DDoS attacks, your code, your traffic spikes, third-party services, network issues between our data center and your users, and any issue we determine was outside our control.”

Read the SLA. Every word. Especially the exclusions.

The Key Numbers in Every SLA

Five things to find in any hosting SLA.

1. Uptime commitment. Usually 99.9%, 99.95%, or 99.99%. Calculated monthly, sometimes annually. The difference between 99.9% and 99.99% is 10x more downtime allowed, but the percentages sound similar.

2. Measurement window. Monthly or annual. Monthly is more customer-friendly. Annual lets providers hide bad months inside good ones.

3. Service credits (the remedy). What you get when they fail. Usually a percentage of your monthly fee, capped at 100% (i.e., one month free). Often prorated – 10% credit for missing 99.9%, 25% for missing 99.0%, etc.

4. Exclusions. What does not count as downtime. This is where providers hide their wiggle room.

5. Claim process. How you request the credit. Many require you to open a ticket within X days of the incident.

A “99.99% uptime” SLA with broad exclusions and a 5% service credit for missing it is not really a 99.99% SLA. Read the details.

Decoding Uptime Numbers

The numbers sound close but mean very different things.

• 99% uptime = 7.2 hours of downtime per month allowed
• 99.9% uptime = 43.2 minutes per month allowed
• 99.95% uptime = 21.6 minutes per month allowed
• 99.99% uptime = 4.3 minutes per month allowed

Most cheap shared hosting promises 99.9%. Better providers promise 99.95% or 99.99%. Enterprise hosting often promises 99.99% with financial backing.

The right number for you depends on your workload. A personal blog can survive 43 minutes of downtime per month. An e-commerce site during the holiday shopping season cannot. Pick the SLA that matches your tolerance.

Common SLA Exclusions to Watch For

These are the clauses that turn an SLA from a real promise into a marketing decoration.

“Scheduled maintenance.” All providers do maintenance. The question is whether maintenance counts as downtime. Best providers: maintenance windows announced in advance, ideally with status page updates. Worst providers: any maintenance they do not count, with no advance notice.

“Force majeure.” Earthquakes, wars, pandemics, government actions. Reasonable. Most contracts have this.

“DDoS attacks.” Increasingly common exclusion. If your site goes down because of a DDoS attack, is that the provider’s fault? Most providers say no. Some add extra DDoS protection as a paid add-on.

“Customer code or configuration.” Your buggy plugin caused the outage? Not the provider’s problem. Reasonable, but sometimes used as an excuse for underlying infrastructure issues.

“Third-party services.” If your hosting depends on a CDN, DNS provider, or upstream network, outages in those services are not the host’s fault. Reasonable, but worth knowing.

“Network issues beyond our control.” Vague by design. Lets providers disclaim almost anything.

“Anything outside our reasonable control.” The catch-all. If they can argue it was outside their control, they do.

The pattern: legitimate exclusions are short and specific. Marketing-driven SLAs have long, vague exclusion lists. Read the exclusions carefully.

Service Credits: What You Actually Get

Most SLAs offer service credits – partial refunds – when they miss uptime targets.

A typical structure:

• 99.9% to 99.0% monthly uptime: 10% credit
• 99.0% to 95.0% monthly uptime: 25% credit
• Below 95.0% monthly uptime: 50% credit (sometimes 100%)

On a $10/month plan, 10% is $1. On a $100/month plan, 10% is $10.

This is not compensation for lost business. It is a small refund on hosting fees. If your e-commerce site lost $10,000 in sales during 4 hours of downtime, a $10 credit does not cover it.

Service credits are usually capped at one month’s fee. They are usually the sole remedy. You cannot sue for actual damages in most cases (look for limitation of liability clauses).

This is the part of the SLA most providers do not advertise.

How to Actually Claim Credits

Most SLAs make claiming credits harder than it should be.

Common requirements:

• Open a support ticket within 3-7 days of the incident
• Provide evidence (screenshots, monitoring data)
• The provider verifies the outage independently
• Credit is applied to next billing cycle

Things that disqualify claims:

• Not opening a ticket in time
• Not having monitoring data
• Outage was during scheduled maintenance (always excluded)
• Provider’s monitoring disagrees with yours
• You did not have paid status during the outage

The catch: you need third-party monitoring (UptimeRobot, Pingdom, Better Uptime) to prove downtime. The provider’s own monitoring will likely show their service was fine.

If you do not have monitoring, you cannot prove downtime. Without proof, no credit.

What to Look For in a Good SLA

A few signs of a real SLA versus a marketing one.

Specific measurement methodology. “We measure by monitoring from 5 external locations every 60 seconds.” Not “we measure uptime however we want.”

Real exclusions list. Short, specific, reasonable. Not a page of legal weasel words.

Generous service credits. At least 25% for missing the target. Best providers offer 100% for major outages.

Independent monitoring. Some providers publish third-party monitoring data publicly. AWS, Google Cloud, Cloudflare all do this.

Past performance matters more than SLAs. Check the provider’s actual uptime over the last 12 months. Status page history is the best indicator. SLAs are promises; history is reality.

Financial backing. For mission-critical workloads, look for providers with significant financial commitments to uptime. AWS, Google, Microsoft offer SLAs with real backing.

What to Watch Out For (Red Flags)

A few warning signs that the SLA is not serious.

“Best effort” language. If the SLA says uptime is provided on a “best effort” basis with no remedies, it is not really an SLA. It is a wish.

Vague measurement. If the SLA does not say how uptime is measured, the provider can measure it however suits them.

Wide exclusions. Pages of exclusions covering “anything we decide was outside our control” means they can opt out of almost any outage.

Tiny service credits. 5% credit for missing 99.9% means the provider loses $0.50 by missing the target. They have no real incentive to meet it.

Long claim windows. If you must claim within 24 hours of an outage, you will forget. Generous providers give 7-30 days.

No public status page. If the provider does not have a public status page showing uptime history, they are not taking uptime seriously.

If you see most of these red flags, run.

Real Examples to Compare

Let us look at how this plays out with real providers.

AWS EC2 SLA. Monthly uptime commitment per region. Service credits from 10% to 100% based on how badly they missed. Excludes customer configuration, force majeure. Clear, specific, financially backed by Amazon. Good.

Cheap shared hosting. Often 99.9% uptime “guaranteed” with 5% credit for missing it. Excludes “any issue we determine was outside our control.” Vague. Hard to claim. Small credit. Marketing-driven.

Cloudflare (CDN/DNS). 100% uptime SLA on the dashboard and DNS. Service credits on monthly fee. Clear exclusions (customer config, force majeure). Financially backed. Excellent.

A typical $5/month VPS host. “99.9% uptime” somewhere in the terms of service. Service credit rarely specified. No public status page. No financial backing. Marketing-only.

The pattern: serious providers have detailed SLAs. Budget providers have vague ones.

How to Use an SLA Practically

A few practical moves.

Read it before you sign up. Most providers publish their SLA on their website. If you cannot find it, ask. If they will not show you, that is itself a red flag.

Calculate the worst case. Take the uptime commitment, calculate the allowed downtime. Is that acceptable for your workload?

Check the exclusions. Are the exclusions reasonable, or do they cover everything?

Look at history. Real uptime over the last 12 months is more useful than the promised SLA. Check status pages, third-party monitoring services, customer reviews.

Set up your own monitoring. Use a free uptime monitor. Without it, you cannot prove downtime.

Keep records. Screenshots, support tickets, monitoring data. When you need to claim a credit, this is your evidence.

Negotiate when you can. Enterprise and business customers can negotiate better SLAs. If you are small, you usually cannot. Pick a provider whose default SLA matches your needs.

The SLA is a tool, not a religion. Use it to filter providers, set expectations, and recover some cost when things go wrong. That is all.

Conclusion

Most SLAs are marketing documents. Some are real contracts. The difference is in the details – measurement methodology, exclusions, service credits, claim process.

You will probably never claim a service credit. Most providers meet their uptime targets most months. But when they do not, the SLA determines whether you get anything back.

Do not pick a host based on the SLA headline. Pick based on past uptime, support quality, and total cost. The SLA is a backstop, not a strategy.

Read the SLA before you sign up. Set up monitoring from day one. Keep records. That is the entire job. Everything else is details.