What a Hosting SLA Actually Promises, and What It Excludes

A hosting SLA is not a promise that your site stays up. It is a document that defines a narrow set of circumstances in which the provider will refund a small portion of your bill.

Read four of them side by side and the structure is nearly identical. What varies is how much of the real world falls outside the definition.

The structure

Every SLA in this category has four parts:

1. A target — an uptime percentage
2. A measurement method — how downtime is counted, and from where
3. A remedy — what you receive, almost always service credits
4. Exclusions — what does not count as downtime

The headline number comes first in the marketing and last in the decision. Part four decides everything.

Targets, and the fact that the digits are not comparable

Some published figures, from the vendors’ own documents:

Provider	Target	Remedy
AWS (compute)	99.99% per region, 99.5% per instance	10% / 30% / 100% of fees, tiered
WP Engine	99.95% standard, 99.99% enhanced	5% of monthly fee per hour of downtime
Kinsta	99.9%, up to 99.99%	Credit table by downtime minutes
Cloudflare (Business)	100%	Formula based on outage minutes × affected customer ratio

Three things make these numbers less comparable than they look.

Scope differs. A 99.99% per-region target and a 99.5% per-instance target belong to the same provider. A region-level metric counts an outage only when an entire region fails, which is a much rarer event than a single instance failing. Reading “99.99%” without asking at what granularity is reading nothing.

The measurement definition differs. Kinsta documents monitoring sites every two to three minutes. Cloudflare’s formula includes an “affected customer ratio”, so an outage affecting a fraction of customers produces a fraction of a credit. Neither is unreasonable; both mean the percentage in the header describes something narrower than a visitor’s experience.

Who measures differs. This is the clause that matters most, and it is rarely read.

“Credits are based on our monitoring”

That sentence appears in one provider’s SLA document verbatim. It is the whole game.

If the provider’s own monitoring decides whether downtime occurred, then the evidence question is settled by the party with the incentive. A distributed monitoring system that happens to be inside the same network as the outage may not see the outage at all. Your uptime monitor — which sits outside and saw everything — is not the record.

One major provider states the counterpart of this explicitly and honestly: the company “is not responsible for comprehensive monitoring of Customer Content; this responsibility lies with Customer.”

So the accurate mental model is: the SLA is a commitment about their view of uptime. If you want a record that contradicts it, you need your own monitoring on infrastructure that is not theirs — which is precisely the case for running an external check even when you self-host everything else.

The exclusions, which is where the outages are

Read the carve-outs across documents and the pattern is consistent. Excluded from the downtime definition, in roughly this order of how often they apply:

• Scheduled maintenance. One host publishes a window of 2am to 5am local, per region.
• Emergency maintenance. Notably, this is often not bounded by a window in advance.
• Force majeure. Standard contract language, and broad.
• Failures of external services. Excluded by name in at least one SLA.
• Your exceedance of plan limits. One SLA excludes “any configuration that exceeds WP Engine’s recommendations or advertised limits.” If your site fell over because you hit the cap you were warned about, the SLA does not cover that.
• Your own actions and equipment. Standard, and fair.
• Third-party networks beyond the provider’s demarcation point.

Look at that list as a whole. It covers plugin conflicts, a saturated plan, an upstream CDN failure, and a maintenance window — the four most common ways a WordPress site goes down. The SLA is a commitment about the provider’s infrastructure, not about your site’s availability.

That is not a complaint. It is what the document says, and it is more useful to know before you need it than after.

The claim process, and the trap in it

Here is the clause most likely to cost you money, and it is documented in almost every one of these agreements.

Kinsta’s SLA requires a written request within 30 days, submitted “using the chat system”, and states that “Failure to comply with this requirement will forfeit Customer’s right to receive an SLA Credit.” A different provider requires you to contact support within 30 days; a third requires notification within 5 business days and a claim by the end of the following billing month.

Note what kind of requirement this is. It is not a deadline for the provider to pay you. It is a deadline for you to notice and act. Miss it and the credit is not denied — it is forfeited, which is a different word, and a stronger one.

There are also technical conditions. One provider requires the claim to include request logs demonstrating the failure — and remember that the provider’s monitoring is the measurement. Assembling evidence that beats their record can be a real task.

The remedy is small, capped, and usually exclusive

Every credit structure here pays a fraction of the affected period’s fees. One caps credits at one month of fees per twelve-month period. Another pays 5% of the monthly fee per hour of downtime.

Now do the arithmetic on the actual loss. If your store was down for four hours on a Saturday, the credit is a small percentage of one month’s hosting bill, and your loss was four hours of revenue. Those numbers are not in the same units, and no SLA in this category attempts to make them so.

Most also make credits the sole remedy, which means the refund is your entire legal compensation for the outage — no consequential damages.

What to do with this

Four practical consequences:

1. Read the exclusions before the target. If maintenance windows and plan-limit exceedances are excluded, and those are your two most likely outage causes, the target percentage is describing a scenario you are unlikely to experience.
2. Keep external monitoring, from somewhere that is not the host. The SLA’s measurement is the vendor’s; yours is yours. When the two disagree, yours is the one that describes what your readers saw.
3. Put the claim window in a calendar. The 30-day or 5-business-day requirement is the clause most likely to actually cost you money, and it costs nothing to set a reminder.
4. Do not choose a host on the SLA number. Every credible provider publishes a plausible figure. The differentiators are the scope of the measurement, the size of the exclusions, and whether the support relationship works — none of which are in the SLA at all.

A credit is a refund of a small percentage of one line item. Treat the SLA as a statement about the provider’s confidence in their own infrastructure, and buy on the operational evidence instead.