Nine fives. Four nines. Five nines. Hosting providers sprinkle these numbers across their marketing materials. But what does an uptime guarantee actually mean, what's typically buried in the fine print, and how do you interpret these percentages in a way that actually matters for your business?
What is uptime?
Uptime is the time a system or service is available and reachable. A server that runs continuously but whose website is unreachable due to a network rerouting counts as downtime in most definitions. A server that fails outright, too. The exact definition varies by provider, and that difference matters.
Uptime is expressed as a percentage of total time in a month or year. 100% uptime doesn't exist, since updates, hardware replacements, and unexpected failures cannot be avoided. The question is how long those periods last and how they're handled.
What those percentages actually mean
A percentage sounds abstract. In minutes or hours per year, it becomes concrete.
99.9% uptime means a maximum of 8 hours and 46 minutes of downtime per year, or about 43 minutes per month. For most business websites, this is an acceptable level if the downtime falls at predictable times (maintenance windows) and not during peak hours.
99.99% uptime (four nines) allows a maximum of 52 minutes per year or 4.3 minutes per month. For e-commerce, API-dependent applications, or services where every minute of downtime means lost revenue, this is a more realistic minimum requirement.
99.999% (five nines) is the level used for critical telecom and banking infrastructure: a maximum of 5 minutes of downtime per year. This requires fully redundant architecture, no planned downtime without transparent communication, and a trained team available 24/7. The infrastructure costs reflect this.
What uptime percentages mean in practice
Downtime calculated over a 365-day year · Per month: divide by 12
What the guarantee typically doesn't cover
Here's where the fine print gets interesting. Most SLAs (Service Level Agreements) contain exceptions that significantly limit the actual protection.
Scheduled maintenance: Most providers don't count maintenance windows as downtime. That's reasonable for unplanned outages, but if a provider performs two hours of maintenance every weekend, the actual availability is considerably lower than the percentage suggests. Pay attention to how and when maintenance is announced.
Force majeure: Force majeure clauses cover everything from power outages to cyberattacks to "circumstances beyond our control." This clause is broad and can be invoked during incidents where the provider has direct control but that are difficult to foresee.
External attacks: DDoS attacks are excluded in many SLAs. If your site is unreachable due to an attack on your provider's infrastructure, that doesn't count as downtime in the SLA calculation. This is a significant exception for organizations that are realistic targets.
User issues: Configuration errors on your end, DNS problems that don't originate with the provider, problems with your own code: these don't count.
What is the compensation worth?
If a provider fails to meet their SLA, you typically receive a voucher or partial credit on your monthly costs. The standard compensation is something like: for every hour of downtime beyond the SLA threshold, you get two hours of hosting free.
That sounds fair, but consider the proportions. An hour of downtime on an e-commerce platform can mean tens of thousands of euros in lost revenue. The compensation is a few euros off your rent. The SLA compensation doesn't cover the damage. Only a solid business continuity approach does.
Some enterprise contracts offer higher compensation, but the practical limit remains: a provider rarely compensates more than the value of the service. If you have critical uptime requirements, the question isn't just "what does the SLA say" but also "how is the architecture designed to prevent downtime."
What an SLA does and doesn't cover
+ Unplanned server downtime
+ Network outages on provider side
+ Power failure in datacenter
+ Software errors by provider
- External DDoS attacks
- DNS problems on your end
- Errors in your configuration/code
- Force majeure
- Downstream providers (CDN, DNS)
Compensation: typically a voucher or service credit. Rarely covers the actual damage from critical outages.
How to evaluate an SLA
When evaluating an SLA, there are five questions you want answered concretely:
How is uptime measured? Do they measure server availability or service availability? Does the provider monitor themselves, or is there an independent monitor? And how do you respond if you disagree with the measurement?
What are the exclusions? Read the exclusions. Not the summary, but the actual SLA text. Are DDoS attacks included? Maintenance? How are those periods communicated?
What's the compensation process? Is compensation automatically applied or do you have to request it? Within what timeframe? Are there thresholds before compensation applies?
What's the underlying architecture? A 99.99% SLA without redundant infrastructure is a promise that's hard to keep. Ask about redundancy: are there multiple power planes, multiple network connections, failover mechanisms?
What are the historical uptime figures? Providers that are proud of their availability publish historical uptime data or status reports. That's worth more than a marketing claim.
Uptime is more than the provider
A hosting provider with 99.99% uptime only guarantees the availability of their platform. Your total availability also depends on your DNS provider, your CDN, your database, external APIs your application calls, and the quality of your own code.
If your DNS provider goes down, your site is unreachable, regardless of your hosting provider's uptime. If your application crashes due to a bug, your server is online but the service isn't available.
Real availability requires end-to-end monitoring, layered redundancy, and a clear distinction between what the provider delivers and what you need to ensure yourself. An SLA is a contractual instrument, not an architecture solution.
Looking for reliable hosting with transparent SLAs? See our cloud solutions or contact support.