Home / Blog / Uptime SLAs decoded

99.9% Uptime Decoded: What a Hosting SLA Actually Covers, in Minutes and Credits

16 October 2026 · SLA & Reliability · 7 min read

Every hosting provider quotes an uptime percentage, and most customers read it as "my site will basically never be down." It helps to translate the number into minutes before you rely on it. A 99.9% uptime commitment allows 43 minutes and 50 seconds of downtime per month. Per year, that's 8 hours and 46 minutes. A provider can take your server offline for a full working day, stay inside 99.9% for that month if the rest is clean, and still print the same badge as everyone else. here's what the percentage means, what the credits are worth, and the exclusions that decide whether the promise is real.

The numbers behind each tier

Uptime percentages compress huge differences into decimals. The standard tiers:

• 99%: 7 hours 18 minutes down per month. Acceptable for a hobby box, not for anything billing.
• 99.5%: 3 hours 39 minutes per month.
• 99.9% ("three nines"): 43 minutes 50 seconds per month.
• 99.99% ("four nines"): 4 minutes 23 seconds per month.
• 99.999% ("five nines"): 26 seconds per month. Usually only quoted for carrier-grade network services, and only meaningful when every component, including power feeds, is redundant.

Each extra nine cuts the allowance by a factor of ten, and the cost of achieving it rises far faster. Going from three nines to four nines means designing for roughly five minutes of total fault budget per month, which rules out single network links, single power feeds, and any maintenance done on live hardware. that's why four nines on a single dedicated server is a marketing number, not an engineering one: one unexpected reboot, a kernel panic or a NIC replacement, spends the entire monthly budget.

What counts as downtime, and what doesn't

This is where SLAs diverge the most. The serious ones define a downtime minute as a minute in which the service fails external monitoring from at least two independent locations. The weak ones count only minutes you noticed, reported, and the provider confirmed. If the SLA says downtime is measured "upon customer notification", the effective commitment is a fraction of the headline, because most outages go unreported for far longer than they last.

Watch the measurement method,. Five-minute polling from a single monitoring location produces false positives from route flaps and misses short outages entirely. One-minute polling from three or more regions is what a provider confident in its network runs.

The exclusions are the actual SLA

Nearly every SLA has a maintenance carve-out. Reasonable in principle: patching, firewall work and planned reboots have to happen. But the definition matters. A carve-out for "emergency maintenance", or for maintenance announced as little as 24 hours ahead, can absorb almost any outage the provider causes. Look for:

• Scheduled maintenance windows that are published, bounded (for example 4 hours, monthly) and excluded from uptime math only if the provider actually stays inside the window.
• Software and customer fault exclusions. Your crashed application, your bad deploy, your expired certificate: correctly excluded. A provider-side control panel bug that power-cycles your box: should count, and often doesn't.
• Force majeure written broadly. Some contracts read as if anything upstream of the rack, including carrier faults inside the facility, is an act of god. Carrier redundancy inside the datacentre is the provider's design choice; an SLA that excludes every network event is covering its own architecture with your budget.
• Denial of service. Most SLAs exclude attacks against your specific service. Ours runs always-on network-level mitigation precisely because we would rather absorb the attack than argue about whose fault the outage was, but if DDoS is excluded, that's a decision, not physics.

What the credits are actually worth

SLA compensation is almost always service credit, not cash, and it's capped. A typical structure pays 5% of the monthly fee for 99.5 to 99.9%, 10% below that, up to a maximum of one month's fees. Run the arithmetic on a real number: on a 150 GBP dedicated server that misses 99.9% by two hours, the 10% credit is 15 GBP. The outage cost you whatever it cost you. The credit is a gesture, not insurance.

Two features separate a fair structure from a decorative one. First, automatic measurement and credit, or at least a claim process that doesn't require you to prove the outage with your own logs within 48 hours. Second, a termination right: if the provider misses the SLA twice or three times in a rolling period, you can leave without paying out the contract. A termination right is worth.

The questions that get honest answers

1. how's uptime measured, by whom, from how many locations, and can I see the monitor?
2. What was your actual measured uptime, per month, for the last year, not the target?
3. Which outages in that period were excluded, and under which clause?
4. Is there a termination right for repeat SLA misses, and what's the trigger count?
5. Are carrier and facility-network events included or excluded?

A provider with real numbers answers these in one email. One that answers with the marketing page again has told you something too.

Where redundancy actually comes from

Uptime is produced before it's promised: dual power feeds into the rack, N+1 UPS and generator upstream, multiple carriers on BGP with failover IPs, and monitoring that pages a human the minute the fault budget starts spending. The SLA documents what the engineering already delivers. If you're comparing providers, compare the facility power design and the network topology; the uptime percentage will follow from those, not the other way round. And regardless of what any SLA says, keep your own backup discipline: no service level agreement ever restored a lost database.

Evaluating a move to a UK-based node? Talk to us and we'll send the measured uptime for our London region, exclusions and all.