Home / Blog / Security and Reliability / How to Read a Hosting SLA and Uptime Claim

Security and Reliability

How to Read a Hosting SLA and Uptime Claim

Almost every hosting provider advertises an uptime percentage — usually 99.9%, sometimes 99.99%. The number looks reassuring and precise. What it actually promises depends on the Service Level Agreement (SLA) behind it: what counts as downtime, what is excluded, how it is measured, and what you get if the promise is broken.

This guide explains how to read those documents, translate percentages into real minutes, and judge whether a claim means anything for your site. It makes no uptime claim for Offshore Hosting — any such commitment, if one exists, must be confirmed and published in Offshore Hosting’s own SLA document. [TO BE CONFIRMED: Offshore Hosting’s SLA terms, uptime commitment, exclusions, and credit policy.]

What an SLA is

A Service Level Agreement is the contractual part of a hosting offer. Marketing pages promise; the SLA defines. A typical hosting SLA covers:

  • The availability commitment (the percentage).
  • How availability is measured, and over what period.
  • What counts as downtime — and what does not.
  • What is excluded.
  • The remedy if the commitment is missed (usually a service credit).
  • How to claim the remedy, and the deadline for claiming.

If a provider advertises “99.9% uptime” but has no SLA document, the number is a marketing statement, not a commitment. Ask for the SLA before you buy.

Translating percentages into minutes

Percentages feel abstract; minutes do not. The standard conversion assumes a 30-day month (43,200 minutes):

Uptime Downtime per month Downtime per year
99% ~7 hours 18 minutes ~3 days 15 hours
99.5% ~3 hours 39 minutes ~1 day 19 hours
99.9% ~43 minutes ~8 hours 45 minutes
99.95% ~22 minutes ~4 hours 23 minutes
99.99% ~4 minutes ~53 minutes
99.999% ~26 seconds ~5 minutes

The jump from 99.9% to 99.99% looks tiny on paper — 0.09 percentage points — but it cuts allowed downtime by a factor of ten, from about 43 minutes a month to about 4 minutes. Hitting 99.99% requires detecting and fixing problems in minutes, usually with automated failover; hitting 99.9% allows a single 30–40 minute outage in a month without breaching the SLA.

Also check the measurement period. A monthly SLA is stricter than an annual one: an annual 99.9% allows the same total downtime spread across the year, so one bad month can be “averaged away” by eleven good ones. A quarterly SLA sits in between. The shorter the period, the more the number protects you.

What counts as “down”?

This is where SLAs diverge most. Read the definition carefully:

  • Network uptime vs service uptime. An SLA that covers “network uptime” may count only the data centre’s network. If the network is up but your server is down, or your site returns errors, that may not count as downtime for SLA purposes — even though your visitors see a dead site.
  • Server vs your site. Some SLAs cover the physical server or the hosting platform, not your individual website. A crashed application on your VPS is your problem, not the provider’s, under most SLAs — and that is usually fair, since the provider does not manage your application.
  • How downtime is detected. Is it measured by the provider’s own monitoring, by external monitoring nodes in multiple regions, and at what interval? A check every five minutes can miss short outages; a one-minute check catches more. Does an outage begin at the first failed check, or only when a second node confirms it?
  • Partial outages. If the site is slow but reachable, or reachable from some regions but not others, does that count? Most SLAs say no — slowness and partial availability are usually excluded.

The question to ask is simple: “If my visitors cannot use my site, does that count as downtime under this SLA?” If the honest answer is “only if the network is down”, the headline percentage is narrower than it looks.

Exclusions: the fine print that matters

Almost every SLA excludes a long list of causes. Common exclusions include:

  • Scheduled maintenance, usually with advance notice (often 24–48 hours or more).
  • Emergency maintenance for security fixes.
  • Your own actions — a bad deployment, a misconfigured DNS record, an expired domain, a broken plugin.
  • Third-party problems — your DNS provider, your CDN, an upstream internet outage outside the provider’s network.
  • Force majeure — natural disasters, war, government action.
  • Abuse or security incidents on your account, such as your site being used to send spam or being attacked (see our guide to DDoS protection and its practical limits).
  • Beta or free services, which are often explicitly excluded from the SLA.

None of these exclusions is unreasonable on its own. The point is to know they exist before an outage, not to discover them when you file a claim. Pay particular attention to the scheduled maintenance clause: if the provider can declare long maintenance windows with short notice, the uptime percentage is easier to meet.

The remedy: credits, not refunds

When a provider misses its SLA, the remedy is almost always a service credit — a discount on a future invoice — not a cash refund. Typical credit tables scale with the shortfall: for example, 10% of the monthly fee if availability falls to 99.5–99.89%, 25% at 99.0–99.49%, and 50% or 100% for worse. Total credits in a month are usually capped at one month’s fee for the affected service.

Three things to check:

  1. Do you have to claim it? Most SLAs require you to file a claim within a deadline (often 7–30 days after the incident). Credits are rarely automatic. If you do not claim, you do not get it.
  2. What evidence is needed? Your own uptime monitoring logs are your evidence. The provider’s status page is theirs. Keep your own records.
  3. Is the credit the sole remedy? Many SLAs state that the service credit is the sole and exclusive remedy for missing the commitment — meaning you cannot also claim damages. A few SLAs allow termination without penalty after repeated failures; that clause is worth more than a small credit if reliability is critical to you.

A credit of 10% of a small monthly fee is a token, not compensation for lost sales. The SLA’s real value is as a signal: a provider willing to put a number in a contract, define how it is measured, and pay a meaningful credit is making a commitment you can hold them to. A provider with a vague percentage and no SLA is not.

How to verify uptime yourself

Do not rely solely on the provider’s status page. It shows problems the provider knows about, measured the way the provider measures them.

  • Use an independent uptime monitor that checks your site from servers elsewhere, every 1–5 minutes, and alerts you when it fails. A one-minute check catches short outages a five-minute check misses.
  • Keep a monthly record of outage times and durations. If you ever need to claim a credit, your own log is your evidence.
  • Compare with the provider’s status page after every outage, and note any discrepancy.
  • Remember that some “downtime” is not the host’s fault. An expired domain, a broken plugin, or a DNS mistake can take a site offline without the hosting being at fault. Check those first before blaming the provider.

Red flags in an SLA

  • No SLA document exists at all, despite an advertised percentage.
  • The percentage is high (99.99% or above) but the remedy is trivial or the claim window is very short.
  • The definition of downtime is so narrow that most real outages would not count.
  • Scheduled maintenance can be declared with little notice and no limit on duration.
  • The SLA applies only to some plans, and you are buying a different one. Always read the SLA for the exact plan you buy.

Key takeaways

  • 99.9% allows about 43 minutes of downtime a month; 99.99% allows about 4 minutes. The difference is tenfold.
  • Read what counts as downtime: network, server, or your site are three different promises.
  • Check the exclusions, the measurement method, and the claim deadline before you buy.
  • The remedy is usually a service credit, not a refund — and you usually have to claim it.
  • Monitor your own uptime independently. Your log is your evidence.
  • This guide makes no uptime claim for Offshore Hosting; any commitment must come from its published SLA.

Sources

  • JustWebWorld, “What Does 99.9% Uptime Mean? Downtime per Month and Year” — https://justwebworld.com/what-does-99-9-uptime-mean/
  • DCHost, “What Does 99.9% Uptime Really Mean?” — https://www.dchost.com/blog/en/what-does-99-9-uptime-really-mean-reading-hosting-slas-without-guessing/
  • Great Cloud Hosting, “Uptime Service Level Agreement” — https://www.greatcloudhosting.com/legal/sla.html
  • WebAlert, “99.9 vs 99.99 SLA Downtime: Exact Minutes and Hours Table” — https://web-alert.io/blog/uptime-sla-explained-99-9-vs-99-99-availability

Sources

  • {‘title’: ‘What Does 99.9% Uptime Mean? Downtime per Month and Year’, ‘url’: ‘https://justwebworld.com/what-does-99-9-uptime-mean/’}
  • {‘title’: ‘What Does 99.9% Uptime Really Mean?’, ‘url’: ‘https://www.dchost.com/blog/en/what-does-99-9-uptime-really-mean-reading-hosting-slas-without-guessing/’}
  • {‘title’: ‘Uptime Service Level Agreement’, ‘url’: ‘https://www.greatcloudhosting.com/legal/sla.html’}
  • {‘title’: ‘99.9 vs 99.99 SLA Downtime: Exact Minutes and Hours Table’, ‘url’: ‘https://web-alert.io/blog/uptime-sla-explained-99-9-vs-99-99-availability’}

← All guides · Knowledge Base

Related guides

Security and Reliability

How to Set Up SPF, DKIM, and DMARC

SPF, DKIM, and DMARC are three DNS records that prove your mail is really from you. This guide explains each one, the setup order, and the safe path to enforcement.

Read the guide →