By Jason Williams — Updated April 22, 2026. Tested 45+ hosts since 2014; filed four real SLA credit claims across three providers (WP Engine, Liquid Web, a small cloud vendor that no longer exists). Two paid, two denied.

The $8 That Proved the SLA Worked as Designed

The SLA credit for a four-hour outage during a nonprofit's year-end fundraising drive — the only day that year they had paid to run Facebook Ads — came to $8. I walked the client through the claim myself: timestamps, UptimeRobot logs, support ticket. Ten days later, the eight dollars posted to their $55/month WP Engine Professional account.

Eight dollars. On a day they had projected $5,000–$8,000 in donations and collected closer to $1,200.

Fatlab Web Support put this cleaner than I can:

"No organization says, 'Our website was offline during our biggest fundraising push, but we got $8 back, so we're fine.'"

That is not a failure of the SLA. That is the SLA doing exactly what it was written to do — cap the provider's liability at a small fraction of the monthly fee, convert the dispute into a credit that can only be spent back with the provider, and require the customer to do the evidentiary work.

I still recommend hosts with SLAs. I just stopped reading them top-down. The uptime percentage on the marketing page is the last thing that matters. The real SLA lives in the excused-downtime list, the claim window, and a four-word phrase — "not redeemable for cash" — that shows up in every legal document I have pulled.

If you are renewing or switching providers in 2026, read the SLA from the bottom up. This article is how.

What an SLA Actually Is, in Two Sentences

An SLA is: (1) a percentage promise about uptime, and (2) a capped payout — usually paid as account credit — when the provider misses that percentage. It is not business interruption insurance. It does not compensate you for lost revenue, lost ad spend, or the staff hours spent explaining to your boss why the site was down.

This matters because the marketing page and the legal page are often writing about two different products. The marketing page says "99.99% uptime guarantee" and shows a shield icon. The legal page — which you signed when you clicked the checkbox — says the credit is capped at the monthly fee, cannot be paid as cash, expires when you cancel, and does not apply to roughly eight categories of downtime.

Fatlab again, who have run this math longer than I have:

"Hosting SLAs are designed to protect the provider, not the customer."

The reverse reading order I use now:

1. Excused Downtime list first. What kinds of outage do not count? If your typical failure mode is in the excused list, the rest of the SLA is decorative.
2. Claim window and evidence requirements second. Five business days? Thirty days? Do you need third-party monitoring logs? If you cannot produce what they require inside the window, you have already forfeited.
3. Credit formula third. Ten times downtime sounds bigger than 5% per hour. Converted to dollars on the same monthly fee, they are closer than you think.
4. Uptime percentage last. Only meaningful after the three above are acceptable.

Read in this order on any SLA and you will know in about five minutes whether it is real cover for your business or just a shield icon.

The Clauses Nobody Reads First

Excused downtime is where the uptime percentage gets quietly discounted. The provider defines a list of outage categories that "do not count" against their SLA — meaning you can be offline and still not be eligible to claim. Below is a consolidated matrix of what gets excused across five common hosting options. I pulled each row from the official SLA legal page in the first week of April 2026.

Table 1. Excused downtime, five providers × six outage types

Two things jump out when you lay these side by side. First, there is no meaningful difference between providers on the excused list — the categories are industry-standard legal boilerplate and roughly 80–90% of what actually takes a small site offline falls into one of them. The WordPress site that crashes after a plugin update? Excused. The WooCommerce checkout that hangs because your PHP memory limit got hit during a traffic spike? Excused. The outage that was "really" an upstream DNS problem? Excused.

Second — and this is the part that reads differently once you notice it — "scheduled maintenance" has an expansive definition. Providers generally reserve the right to declare maintenance windows with short notice (often 24–48 hours), and any downtime inside a declared window does not count. I have seen a declared "emergency maintenance" window that closed 11 minutes before a real incident began and ran for three hours after.

This is the bit where passive voice usually does the work. The clauses do not say "we exclude these downtimes" — they say "these downtimes are classified as excused." The actor is the provider. They define the categories, and they apply them. Your recourse, if you disagree, is arbitration.

Claim Windows and the Evidence You Need to Produce

Even if your outage survives the excused-downtime filter, you have to file a claim inside the window and with the evidence the provider specifies. Miss either and the claim is denied on procedure.

Table 2. Claim windows and evidence required

The 5-business-day window at Liquid Web is the one that burns people. If your outage happens on a Friday afternoon of a long holiday weekend and you are not monitoring on Monday, you can genuinely run out of time. I had it happen to a client — the outage was legitimate, the logs were clean, the credit was owed. By the time we pulled the evidence together on day 9, the reply came back: "outside claim window — no credit issuable." Nobody at Liquid Web was wrong. The window had simply closed while we were still looking at it, and the sinking feeling of realizing a valid claim had expired on a technicality is the thing I remember more than the missed money.

The evidence requirement is the quieter trap. WP Engine's SLA explicitly leaves the burden of documentation on the customer. If you do not have UptimeRobot or StatusCake configured — which costs about $0 on the free tier for up to 50 monitors at 5-minute resolution — your only evidence is the provider's own status page. And the provider's status page is the one they control. I watched a provider retroactively update a status page entry from "incident" to "performance degradation" after the fact. The uptime monitor I had set up on another host was the only reason we kept receipts.

5% × Hours, 10× Downtime, or % of Monthly — Converted to the Same Dollar Amount

This is the section where the marketing-page differences collapse. Every provider uses a different formula for calculating the credit. "Ten times the duration of downtime" sounds enormously more generous than "5% of your monthly fee per hour of unavailability." On a normalized monthly fee and a normalized outage, they are not.

Below I converted each major formula to the same scenario: a 2-hour outage (beyond the excused threshold) on a hosting plan costing $100 per month. I am using $100 because it is a clean divisor, not because it is any specific plan — WP Engine's Professional tier runs $55/month and Growth is $109, so $100 is near the middle of that band.

Table 3. Credit formulas converted to dollars (2-hour outage, $100/month plan)

Here is the surprise. Liquid Web's "10×" multiplier — marketed on their 100% uptime guarantee page as generous and industry-leading — converts to the smallest dollar credit in the table. Because the multiplier is applied to time, not to the monthly fee, and a $100/month plan works out to roughly $0.14 per hour, 20 hours of service credit is under $3.

Meanwhile WP Engine's 5%-per-hour formula, which sounds modest, produces a larger dollar credit on the same outage. AWS's tiered 10%/30% steps are by far the most generous in raw dollar terms, but only trigger if you have architected your workload across multiple Availability Zones — the Instance-level SLA is only 99.5%, meaning a single EC2 instance can be offline for 3 hours and 39 minutes per month and AWS still considers itself compliant.

The credit-nature column is the one I would circle. Look at what WP Engine actually commits to in its SLA:

"Service Credits may not exceed 100% of the applicable monthly Fees, may not be carried over or aggregated, are forfeited at the expiration or termination of the Agreement, and will not be paid or provided as a refund."

Kinsta's phrasing is nearly identical:

"SLA Credits have no intrinsic or cash value, are not redeemable for cash, and are nonrefundable. Unused SLA Credits will expire upon termination of Customer's Hosting Plan."

The implication is worth stating plainly: if your response to a serious outage is "this relationship is over, I am leaving," you also forfeit the credits. The SLA pays you to stay with the provider who just failed you. It does not pay you to leave.

There is a historical anchor for this whole architecture. In 2012 the UK's Advertising Standards Authority took up a complaint that Rackspace's "100% Uptime Guarantee" slogan was misleading. The ASA ruled in Rackspace's favor, concluding, per ITPro's coverage:

"[ASA concluded that] consumers would understand that the claim '100% Uptime Guarantee' meant they would be compensated if the Rackspace Cloud network was unavailable, and concluded the claim was not misleading."

Read carefully, that is the regulator saying out loud what the legal documents only imply: "100%" is contractual language about compensation, not a physical promise about network availability. Once you have seen it named explicitly, you cannot un-see it in every other marketing page.

The Real Question Is Not Which Host Has 99.99%, It Is Which Business Needs It

Uptime percentage is the last thing to look at, but it does eventually matter — just not in the way the marketing pages frame it. The useful translation is from percentage to allowed minutes of downtime per month, which the provider considers compliant and will not credit.

Table 4. Uptime % → monthly allowed downtime → revenue impact

"99.9%" is the number that catches people. It sounds like "almost never down," but it is 43 minutes and 49 seconds per month of fully SLA-compliant downtime — none of which generates a credit, because it is inside the allowance. For a WooCommerce store doing $500/hour, that is around $365 of revenue that the SLA is explicitly not covering. Over 12 months of compliance, that is $4,380 of uncompensated revenue inside the "99.9% uptime guarantee."

Rough rule I use when clients ask which SLA tier they need, entirely based on business type:

• Marketing / content site, low direct revenue per hour. 99.9% is fine. The gap between 99.9% and 99.99% costs more in hosting than it protects in lost revenue for most sites doing under $1,000/month in attributable pipeline.
• E-commerce with meaningful cart volume. Push for 99.95% at minimum, and architect for redundancy at the application layer (a backup static maintenance page, a cached product catalog, a payment processor fallback). The SLA will not rescue a checkout outage on Black Friday.
• Mission-critical SaaS or anything with SLA-to-your-customers. 99.99% or better, multi-region, and you cannot rely on the hosting SLA to fund your own SLA commitments. Stack third-party business interruption insurance on top.

What I stopped doing is comparing providers by their headline percentage. I would rather work with a host at 99.9% who has a clean claim process and a clear credit formula than a 99.99% provider whose excused-downtime list covers everything that actually takes sites down.

Verdict: What an SLA Can and Cannot Do

After four real claims across three providers (and two denials — one on claim-window grounds, one on "customer application error," which was true but still frustrating), here is the honest edge of what SLAs are good for.

What an SLA can do:

• Give you a documented reason to leave a provider after a serious outage — the claim process itself is useful as a paper trail for an eventual arbitration or dispute.
• Return single-digit to low-double-digit dollar credits for ordinary bad months. On WP Engine Startup at $30/month, a typical small-outage credit is under $5. On Growth at $109, it is under $25. Treat it as a minor rebate, not a recovery.
• Expose quickly, via the credit formula and excused-downtime list, how seriously the provider takes their own promise. A host that refuses to publish a full SLA — or that buries the excused list — is telling you something.

What an SLA cannot do:

• Compensate for lost revenue or lost customer trust. A credit is not a refund and is explicitly not cash.
• Cover application-level outages (plugin conflicts, your own config, resource-limit hits) — which in my experience are 70%+ of real site downtime.
• Survive your cancellation. If you leave, unused credits are forfeited. The SLA pays you to keep paying.

I still recommend hosts with published SLAs over hosts without them — the act of publishing a full legal SLA is itself a signal. But I stopped telling clients the uptime percentage is the number that matters. The number that matters is the dollar value of the credit on a realistic outage, and the number of outage categories that your real business is likely to hit but the SLA has already excused.

Where this reading framework stops working: low-tier shared hosting plans that do not publish a real SLA at all. The whole method depends on there being legal text to read against. If you are paying under about $15/month and the only "uptime guarantee" is one sentence on the sales page, the Frame does not help you — you are simply uninsured, and the honest response is either to accept that risk or to move to a tier that publishes a full SLA you can apply this method to.

If you are in the middle of a renewal decision and you want to do one thing this week: open the SLA page you are about to re-sign, scroll to the excused-downtime section and the claim window, and read those two paragraphs first. Then decide whether the uptime percentage on the marketing page is a promise or a shape.

For the nonprofit with the $8 credit — we switched them the following January. Not because the SLA failed them. Because the SLA worked exactly as written, and what was written was not what they thought they had bought.

FAQ

Can I stack SLA credits across multiple downtime events to get more than a month free?

No. WP Engine's SLA is explicit — Service Credits "may not exceed 100% of the applicable monthly Fees, may not be carried over or aggregated." Kinsta uses the same language in substance. Even a catastrophic month with multiple separate outages caps the credit at the monthly fee you paid. This is the single clause that most readers miss when they see a big-sounding multiplier like Liquid Web's 10×.

Does a plugin or theme conflict count as downtime for SLA purposes?

No. Application-level errors — plugin conflicts, theme bugs, your own PHP code, a WordPress core update that broke something — are excused at every major host I have checked. This is consistent across WP Engine, Kinsta, Liquid Web, Cloudways, and AWS. If you are on managed WordPress and your outage was caused by a bad update, the host's SLA does not apply, even if the update was pushed automatically. You can still often get the incident fixed under standard support, but it will not generate a credit. In practice this excuses the majority of real managed WordPress outages.

Is Liquid Web's 100% uptime guarantee actually possible?

Not as a physical promise. The UK Advertising Standards Authority addressed this in 2012 in a ruling on Rackspace's identical slogan. Per ITPro's coverage, the ASA concluded that "consumers would understand that the claim '100% Uptime Guarantee' meant they would be compensated if the Rackspace Cloud network was unavailable, and concluded the claim was not misleading." Translation: the regulator explicitly accepted that "100%" is contractual language about compensation, not a statement about network physics. Liquid Web's 100% offer works the same way — they will credit you when there is downtime, but downtime will happen, and the credit (per Table 3) is small in dollar terms.

What do I need to document for an SLA claim to not be denied?

Three things, filed inside the claim window: (1) third-party uptime monitoring logs with timestamps — UptimeRobot or StatusCake on the free tier is enough; (2) a screenshot of the provider's status page entry for the same window; (3) the submission via the provider's specified channel (usually a support ticket tagged as SLA claim, not general chat). If you do not have third-party monitoring, you are relying entirely on the provider's own status page as evidence — which they control and can revise. Set up monitoring on day one of the contract, not day one of the outage.

Can I negotiate a better SLA on an enterprise plan?

Yes — this is one of the few real levers, and most buyers pull it in the wrong direction. Kinsta and WP Engine both offer Enhanced SLAs on custom enterprise plans, on custom enterprise plans (contact sales for pricing): 99.99% on Kinsta, bespoke uptime and response-time commitments on WP Engine.

The wrong ask: "We need 99.99% instead of 99.9%." I have watched this line of negotiation produce a fresh contract with an improved percentage and an entirely unchanged excused-downtime list — the provider gave up a number they almost never have to pay on and kept every carve-out that actually lets them refuse claims.

The ask that moves the real numbers: "Our business does $X/hour in attributable revenue. We need two things — (1) tighten the excused-downtime definition so maintenance windows declared on less than 72 hours' notice are not excused, and (2) a named first-response SLA under 30 minutes with a billing penalty for breach." The first change expands how many real outages you can claim on. The second shortens the time you are bleeding revenue before a human picks up the ticket. Those two numbers change your outcome when an incident actually happens. The headline uptime percentage rarely does.

Should I pick Liquid Web's 100% over AWS Region-level 99.99%?

Depends on the workload. For a single-site WooCommerce store where you want one support channel to call, Liquid Web's flat 100% SLA and single-ticket claim path are simpler to operate than AWS's multi-AZ architectural requirement and billing-credit-request flow. For a high-traffic SaaS already running in multiple regions, AWS's Region-level 99.99% SLA with the 10%/30% credit steps is substantially more generous in raw dollars, but only if you have actually architected across Availability Zones — a single-instance deployment is on the 99.5% Instance-level SLA, which allows 3 hours 39 minutes of monthly downtime. The right answer is not the bigger percentage; it is whether your architecture matches the SLA tier you think you are buying.