Hosting SLAs read like comfort food until something breaks. "99.9% uptime." "24/7 support." "Enterprise-grade infrastructure." The words are familiar. The fine print is where you learn what you actually bought.
We are not going to tell you every SLA is useless. Some providers document real commitments with clear remedies. Many others paste marketing into a PDF and call it a contract. Here is how to read one like someone who has sat through enough outage calls to know which clauses matter.
Uptime: the number and the math
99.9% sounds impressive until you do the arithmetic. That is about 43 minutes of downtime per month, or roughly 8.7 hours per year. 99.99% is under 5 minutes a month. Ask:
- What counts as downtime? (Just the web server? DNS? The control panel? Email?)
- Who measures it, and can you see the logs?
- Are scheduled maintenance windows excluded? For how long, and how much notice?
- Does a partial outage count, or only a full blackout?
If the SLA only covers network reachability to the data centre and your site is down because PHP crashed, you may have "uptime" on paper and an angry boss in your inbox.
Support response vs support resolution
"24/7 support" often means someone acknowledges the ticket at 3 a.m. It does not mean someone fixes it at 3 a.m. Look for separate language on:
- Initial response time (first human reply)
- Resolution time (problem actually fixed)
- Severity tiers (site down vs "how do I add an email alias")
- Channels (ticket only, or phone for emergencies)
For a Canadian business running payroll Friday afternoon, "we responded within four hours" is not the same as "we restored service within four hours."
Credits are not refunds
Many SLAs promise a service credit if uptime misses the target. Read what that credit applies to:
- Usually it is a percentage off next month's hosting bill, capped at 100% of that month.
- Often you have to request it within 30 days with evidence.
- It rarely covers lost revenue, staff time, or customer churn.
A $29 credit after a six-hour ecommerce outage is not meaningful compensation. It is a gesture. Know that going in so you size your own risk correctly.
Exclusions: the list that voids everything
Every SLA has a paragraph of things the provider is not responsible for. Common ones:
- Your code, plugins, or misconfiguration
- DDoS attacks beyond a certain size
- Third-party services (payment gateways, CDNs you chose)
- Force majeure, upstream carrier issues, acts of God
- Issues you caused by ignoring upgrade notices
Some exclusions are reasonable. Others are so broad that the uptime guarantee is decorative. If "customer applications" covers anything running on your VPS, the SLA might not protect you from much at all.
Data, backups, and security language
SLAs often focus on availability and skip recovery. Check whether the document says anything about:
- Backup frequency and retention
- Data centre location and redundancy
- Security incident notification timelines
- Who is responsible for patching the OS vs the app
If backups are not in the SLA, they are a separate conversation. We wrote about that gap in our backups that actually restore piece.
What to ask before you sign
- Can I see a real incident report from the last year? (Redacted is fine.)
- What happened the last time you missed your SLA, and how was it handled?
- Is phone support included for severity-1 issues on my plan tier?
- Where is my data physically hosted, and does that match what sales told me?
- What is not covered that I might assume is?
A provider who answers plainly is usually a provider who has been through outages without hiding behind legal text.
How we think about it at Swift Host
We would rather set honest expectations than paste "five nines" on a brochure. Managed hosting here means named support, documented environments, daily backups, and Canadian infrastructure you can point to on a map. If something goes wrong, we work the problem with you. That relationship matters more than a credit coupon when your store is offline.
Our team responds within an hour on business inquiries, and emergency recovery gets prioritized. Read the SLA if we send one, but also ask us the questions above. Good hosts welcome them.
Bottom line
An SLA is a map of what the provider will admit responsibility for. Read the exclusions, separate response from resolution, and do the uptime math yourself. If the document only makes sense in a sales deck, treat the marketing number accordingly.
Comparing hosts and want a straight read on what you are looking at? Talk with Swift Host. Bring the SLA. We will tell you what it actually means.
