Innovations GRCGuidesContracts · SLA

Reading a hosting SLA: the ten lines that matter

Every provider prints a big uptime percentage. The percentage is almost never the problem. The problem is the ten quieter lines around it that decide what happens when the number is missed. Here is how to read them in ten minutes.

Disclosure. Innovations GRC publishes its own SLA and sells managed hosting. Some provider links on this site are affiliate links; see the affiliate disclosure. Use this checklist on our SLA too.

A service level agreement is a promise with a price attached. "99.9% uptime" sounds like a guarantee that the site will almost always be up. Read literally, it means the provider will give you some money back if their own measurement, after exclusions, falls below a threshold, and that you will have to ask for it. Whether that is worth anything depends on the lines below.

1. The percentage, converted to minutes

Percentages hide the scale. Over a 30-day month, 99.9% allows about 43 minutes of downtime; 99.95% about 22 minutes; 99.99% about 4 minutes; 99.5% allows three and a half hours. Convert the number before judging it, and compare it with what an hour offline actually costs you.

2. How uptime is measured, and by whom

This is the line that matters most and is most often missing. Is uptime measured by the provider's own monitoring, from inside their network, where a problem with their edge or DNS would never be seen? Or from outside, from several locations, at a stated interval? What counts as "down": any error, or only a total outage? Two consecutive failed checks, or ten minutes of failure? A provider that measures itself, generously, will never miss its SLA. Look for external measurement, a check interval and a definition of downtime written in numbers.

3. Scheduled maintenance

Most SLAs exclude scheduled maintenance from downtime, which is reasonable, as long as there are limits. Read for: how much notice is required, how many hours per month are allowed, whether maintenance is restricted to off-peak hours for your business, and whether maintenance that overruns its window counts as downtime. An SLA with unlimited, unannounced maintenance excludes everything.

4. The exclusions list

Every SLA excludes some causes: your own code, your own DNS changes, upstream internet failures, force majeure. The question is how broad the list is. "Issues caused by third parties" can be stretched to cover the provider's own cloud supplier, which is to say every real outage. "Issues outside our reasonable control" can mean anything. A fair list is short, specific, and does not exclude the provider's own suppliers.

5. Response versus resolution

"We respond to critical tickets within 15 minutes" means a human acknowledges the ticket, not that the problem is being fixed. Look for both a response target and a statement about what happens next: that work continues until service is restored, with updates at a stated frequency. Also check the hours: a one-hour response "during business hours" leaves Friday evening to Monday morning uncovered.

6. Severity definitions

Response targets usually depend on severity, and the provider usually decides the severity. Read how they define it. If a dead checkout on a store can be classified as "degraded" rather than "outage" because the home page still loads, the fast response target does not apply to the failure that actually costs you money.

7. The credit table and its cap

Credits are almost always a percentage of the monthly fee: 10% for a small miss, up to 50% or occasionally 100% for a catastrophic one. Two things to check. First, the cap: a credit capped at 10% of a $50 plan is $5 for any outage of any length. Second, the currency: a credit against future invoices is worth nothing if you leave. The honest version applies credits automatically and refunds them in cash if the plan is ending.

8. How to claim, and the deadline

Many SLAs require you to notice the outage, document it with your own evidence, and claim within a short window, often 7 to 30 days, or the credit is forfeited. That is a filter: providers know most customers never claim. An SLA that applies credits automatically from the provider's own monitoring is making a different kind of promise, because it costs them something to miss.

9. Backup and recovery objectives

Uptime SLAs rarely mention data, yet losing data is worse than losing an hour. Look for a recovery point objective, the maximum data you can lose, and a recovery time objective, how long a restore takes. If neither appears, the provider has made no commitment about your data at all, whatever the marketing page says about backups. The backups guide covers what the numbers should be.

10. The remedy clause

Near the end there is usually a line stating that credits are your "sole and exclusive remedy". That is standard, and it means you cannot sue for the lost sales; the credit is all you get. It is not a reason to reject an SLA, but it is a reason to size your plan and your own insurance on the assumption that the SLA will not make you whole.

The two-minute version. Convert the percentage to minutes. Find who measures and how. Check maintenance limits and the exclusions list for the word "third parties". Separate response from resolution. Find the credit cap and the claim deadline. Look for RPO and RTO. If any of those is missing, that is the answer the provider did not want to give.

How ours reads against this list

We wrote the Innovations GRC SLA after years of reading other people's, so it answers each line directly: external measurement from several regions at a stated interval, maintenance limited to four announced hours a month, a short exclusions list that does not cover our own suppliers, response targets with hours stated and work continuing until restored, severity definitions you can read, credits applied automatically and refunded in cash if the plan is ending, and recovery objectives for every plan. Read it with this checklist and tell us if we have missed a line.