Reseller Hosting SLA and Uptime Promises

Disclosure: To keep our review of Reseller Hosting SLAs completely unbiased, we disclose that this article contains affiliate links, but we maintain full editorial independ

This is for agencies and freelance resellers who quote an uptime number to clients without ever reading the SLA behind it. An SLA (service level agreement) is a contract, not a marketing claim, and the gap between what a hosting company advertises and what it’s actually obligated to do when a server goes down is where resellers get burned — usually the first time a client asks “what happens now?” during an outage.

What an uptime percentage actually means in hours

Uptime guarantees get thrown around as marketing copy, but the math behind them is fixed and worth memorizing so you can translate a percentage into something a client understands:

Advertised uptime	Allowed downtime per year	Allowed downtime per month
99.9%	~8 hours 45 minutes	~43 minutes
99.95%	~4 hours 22 minutes	~21 minutes
99.99%	~52 minutes	~4 minutes
100% (contractual)	0, but with defined exceptions	0, but with defined exceptions

Liquid Web is one of the few hosts that publishes a 100% network, power, and hardware uptime guarantee at the infrastructure level, but that guarantee (like almost every host’s) explicitly excludes scheduled maintenance windows, and it pays out as a prorated account credit — not a refund, and not compensation for the client’s own lost business. That distinction matters more than the headline number.

What to actually check in the fine print

The advertised percentage is the least useful part of an SLA. What determines whether it protects you is buried further down:

What counts as “down.” Most SLAs define downtime narrowly — total server unresponsiveness — and specifically exclude a slow site, a misconfigured plugin, DNS propagation delays, or scheduled maintenance. A site that loads in 12 seconds isn’t “down” under most SLA definitions, even though it functionally is for the client.
Who has to file the claim, and when. Several providers require you to open a support ticket within a fixed window (commonly 24–30 days) after the outage to claim a credit; if you miss the window, the credit is forfeited even if the outage clearly happened.
What the remedy actually is. Virtually every hosting SLA pays out in account credit toward future hosting, not cash, and the credit is usually capped as a percentage of that month’s bill — not the client’s lost revenue.
What’s excluded. Scheduled maintenance, DDoS attacks, force majeure, and issues caused by the client’s own code or plugins are near-universal exclusions.

The status page tells you more than the SLA does

An SLA describes what the provider promises to do after an outage. A public status page shows you what has actually happened. Before committing a client’s site to a host, check the provider’s status page history (most publish 90 days) for the frequency and length of past incidents, not just the current SLA wording. A host with a modest 99.9% SLA but a clean 90-day incident history is a safer bet in practice than one advertising 99.99% with a status page full of red banners.

What resellers get wrong when quoting SLAs to clients

The single biggest mistake is promising a client a better uptime number than your own upstream provider actually guarantees you. If your infrastructure is on a host with a 99.9% SLA and you tell a client “we guarantee 99.99% uptime,” you’ve created a liability with no infrastructure behind it — you can’t credit what your own supplier won’t credit you. Whatever you promise a client should be your upstream provider’s guarantee minus a margin, not a marketing round-up.

The second mistake is treating the SLA credit as risk management. A prorated hosting credit does nothing for the client’s lost sales during a Black Friday outage. Real risk management is architectural — automated backups with tested restores, a staging environment, and for higher-stakes clients, a managed host with real redundancy (multiple availability zones, automatic failover) rather than a single server with a good-sounding SLA on paper.

[AFFILIATE CTA: Liquid Web]

Shared hosting SLAs are weaker than they look

An SLA on a cheap shared-hosting reseller plan (the kind sold by companies like HostGator or Bluehost’s reseller programs) usually applies to the shared server as a whole, not to any individual client site. If a noisy-neighbor account on the same server overloads shared resources and slows every site down, that’s rarely treatable as a qualifying SLA outage even though the client’s site is effectively unusable during that window — it doesn’t meet the strict “unresponsive” definition most SLAs use. This is one of the strongest arguments for moving higher-value clients to an isolated VPS or a cloud platform like Cloudways or WP Engine, where the SLA and the resource isolation both apply per-account rather than per-shared-server.

Verdict: what actually protects a client

For most small-to-mid client sites, a mainstream managed host with a 99.9%–99.99% SLA, a clean recent status-page history, and same-day support response is genuinely sufficient — you don’t need to chase the highest advertised number. For clients where downtime has a real dollar cost (active e-commerce during peak season, SaaS products, anything with paying subscribers), pair the SLA with actual redundancy: automatic failover, load-balanced servers, or a managed platform built around uptime rather than a single VPS with a strong-sounding promise attached to it.

FAQ

Will a hosting SLA ever cover my client’s lost revenue during downtime?
Essentially never. SLA remedies are almost universally account credit toward future hosting, capped as a percentage of the monthly bill, not compensation for the client’s own business losses.

Is 99.9% uptime good enough for a client’s e-commerce store?
For most small stores, yes — that’s under 9 hours of allowed downtime a year, and in practice well-run hosts perform better than their contractual floor. For high-volume stores where an hour of downtime is expensive, look at 99.99% infrastructure or a redundant/managed setup instead of relying on the SLA number alone.

Should I put an uptime guarantee in my own client contracts?
Only if you can actually back it with your upstream provider’s SLA, and only after you’ve subtracted a safety margin. Never quote a client a better number than your own host guarantees you.

How do I actually file an SLA credit claim if a host goes down?
Open a support ticket referencing the outage as soon as you notice it, include timestamps and, if possible, monitoring evidence (uptime monitor logs), and do it within the provider’s claim window — commonly under a month. Waiting until you “have time” is the most common way resellers forfeit a legitimate credit.