Hosting Uptime SLAs: What 99.9% Really Means
An uptime SLA sounds reassuring until you do the math. What 99.9 uptime allows, what SLA credits actually pay, and how to verify uptime yourself.
By Matthew Zhao · Editor, Hosted EZ

An uptime SLA is a service level agreement: the host's written promise about availability and what you get when the promise breaks. Every host advertises one, usually 99.9%, so the badge itself tells you nothing. The useful information is in the math, the exclusions, and the compensation, and all three favor the host.
This guide reads the fine print for you. See how to choose a web host for where uptime fits in the wider decision, and our migration guide if repeated outages have already decided it.
What an uptime SLA actually promises
Read the SLA before you buy, not after an outage. It defines three things: the availability target, how downtime is measured, and what the host owes you when it misses. Each definition has room for interpretation, and the host wrote all three.
Note who does the measuring. Most SLAs count only downtime the host's own monitoring confirms, which is exactly the monitoring that failed to prevent the outage.
The math behind 99.9 uptime
Percentages hide the real numbers. A 99.9 uptime target still allows roughly 43 minutes of downtime per month, or nearly nine hours per year, without breaching the SLA. At 99.99% the allowance drops to about four minutes a month; at 99.5% it balloons past three hours.
Do this arithmetic for any target a host advertises. "Three nines" sounds close to perfect and permits a bad afternoon every month.
Timing matters as much as the total. Forty-three minutes spread across a month as scattered blips passes unnoticed; the same allowance spent as one outage during your busiest hour is a visible, expensive day. SLAs count minutes and ignore timing, which is one more reason the badge alone tells you little.
What SLA credits are worth
When an SLA is breached, the standard remedy is account credit: a percentage of your monthly fee, claimed manually, capped at the month's bill. On a plan costing a few dollars a month, a serious outage might earn you pocket change.
No hosting SLA compensates lost sales, signups, or reputation. Treat the credit as an honesty signal from the host, not insurance.
The exclusions that hollow out the promise
Scheduled maintenance almost never counts as downtime, and some SLAs let hosts schedule "emergency maintenance" retroactively. Other common exclusions: DNS problems, attacks, upstream network failures, and anything classed as your fault.
Count the exclusions before you weigh the target. A 99.9% promise with aggressive exclusions is weaker than an honest 99.5% measured plainly.
Verify hosting uptime yourself
Do not take hosting uptime on faith; measure it. Point a free uptime monitor at your site and let it check every minute from outside the host's network. During the refund window, this is the cheapest due diligence available. We cover the tooling in our guide to uptime monitoring.
Check the host's public status page history too. A page with honest incident write-ups is a better signal than any badge on the pricing page.
How to claim an SLA credit
Claim windows are short, often seven to thirty days after the incident, and the burden of proof is yours. Submit the ticket with your monitor's log: timestamps, check locations, and duration.
This is where your own monitoring pays for itself. Without independent records, the claim becomes your recollection against the host's dashboard.
Keep the evidence
Keep your monitor's alerts and monthly reports somewhere durable. A dated log turns "the site felt flaky in March" into a specific claim a host cannot wave away.
A note on architecture: a CDN, a network that serves cached copies of your pages from many locations, can keep parts of a site visible even when the origin server is down. Cloudflare's explanation of CDNs covers how: Cloudflare's explanation of CDNs.
One last check before you rely on it
Before you commit, find three things in the SLA: the measured target, the exclusion list, and the claim procedure with its deadline. If any of the three is missing or vague, price the plan as if the SLA did not exist, because in practice it may not.
Bottom line
An uptime SLA is a refund policy for downtime, not a guarantee your site stays up. Do the minutes-per-month math on the advertised target, read the exclusions, and run your own monitoring so any claim rests on your evidence rather than the host's.
Frequently asked questions
Is 99.9 uptime good enough for a small site?
Usually, yes. Nine hours of scattered annual downtime is survivable for a blog or brochure site. A store or booking site feels every outage in revenue, so aim for a stronger target, independent monitoring, and cached pages that keep working during origin outages.
Does an uptime SLA cover scheduled maintenance?
Almost never. Maintenance windows are excluded from downtime calculations in nearly every hosting SLA, which is reasonable when windows are announced and bounded. The red flag is wording that lets the host declare maintenance after the fact.
What does uptime monitoring cost?
Nothing, at small scale. Free tiers in 2026 typically check your site every minute from multiple locations and alert you by email. That is sufficient both for knowing your real uptime and for documenting an SLA claim.
Does an uptime SLA cover email and databases?
Read how the SLA defines the service. Many promise availability for the web server only, so a mail outage or a database failure that leaves your site half-broken may not count as downtime at all. If email or a database matters to your business, confirm the SLA names it explicitly. A service the agreement never mentions is a service it does not cover.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.


