99.9% uptime sounds comfortably close to perfect. In a hosting proposal, it can feel like proof that a website will scarcely ever disappear. The percentage usually answers a narrower question: whether a defined part of a service was considered available during a defined measurement period.
That distinction matters because the server can be running while a form, checkout or login is failing. Before comparing strings of nines, it is worth understanding what the promise covers, how failure is detected and what happens next.
The missing 0.1% is real time
Uptime is commonly expressed as the percentage of a period during which a service is available. Assuming continuous 24-hour operation and no contractual exclusions, the figures translate approximately as follows:
- 99.9% uptime: up to 43 minutes of downtime in a 30-day month, or 8 hours 46 minutes in a 365-day year.
- 99.95% uptime: about 22 minutes in a 30-day month, or 4 hours 23 minutes in a year.
- 99.99% uptime: about 4 minutes in a 30-day month, or 53 minutes in a year.
These are mathematical equivalents, not predictions. A supplier may measure availability monthly rather than annually, and a contract may exclude planned maintenance or particular causes of failure. Downtime can also arrive in one painful block rather than being spread neatly across the calendar. Forty-three minutes during a major campaign or peak booking period may matter far more than the same duration late at night.
What does available actually mean?
An uptime figure is only useful when the measured service is clear. A hosting provider might measure its network, a virtual server or a particular endpoint. That does not automatically prove that the complete website is usable.
The GOV.UK guidance on uptime and availability highlights the many systems and suppliers on which a digital service may depend. It also notes that some services exclude scheduled maintenance from their calculations. Neither practice is necessarily unreasonable, but both affect what the headline percentage means.
Useful questions to ask include:
- Which component does the guarantee cover: the network, server, website or complete customer service?
- How and from where is availability measured?
- Do severe slowness, partial failures or incorrect pages count as downtime?
- Which maintenance periods, supplier failures or customer-controlled issues are excluded?
- Is performance assessed monthly, annually or over another period?
- What evidence and reporting will be available if the target is missed?
Two providers can both advertise 99.9% while making materially different promises. The small print is part of the product.
A website can be online and still fail its customers
A basic monitoring check may confirm that the homepage returns a successful response. Meanwhile, a contact form could stop delivering messages, a payment provider could reject every transaction or a booking could appear complete without reaching the system used by staff.
These are not theoretical edge cases created to frighten procurement teams. They are ordinary consequences of modern websites relying on several moving parts. The visible pages, database, email delivery, background tasks and third-party services may each fail independently.
The GOV.UK monitoring guidance recommends tracking user-related measures, such as whether people can complete a task, alongside technical measures. That principle is useful well beyond government services.
Basic uptime monitoring remains valuable because it can identify a total outage quickly. For a straightforward informational website, checks on important pages may be proportionate. A website handling sales, bookings, accounts or operational workflows may need broader monitoring of customer journeys, integrations, scheduled processes and application errors. Roled's overview of full platform monitoring explains how this wider view differs from a simple availability check.
An SLA is not an incident response plan
A service level agreement, usually shortened to SLA, sets contractual expectations and may offer service credits when a supplier misses them. A credit can acknowledge failure, but it does not recover abandoned orders, restore customer confidence or explain who will fix the problem.
Detection is only the first clock. Someone must receive the alert, understand it, gain access to the right systems, investigate the cause and restore service. If a website matters outside office hours, the support arrangement needs to reflect that. An alert at 8pm on Friday is little comfort if nobody is responsible until Monday morning.
For important services, the response plan should make clear who owns the incident, how suppliers are escalated, how customers or staff will be informed and how recovery will be verified. Availability also intersects with recovery planning: a hosting failure may require the website to be restored elsewhere. As Roled's guide explains, a backup is not the same as a tested recovery plan.
Choose reliability around business consequences
Not every company needs the cost and complexity associated with 99.99% availability. A brochure website with predictable office-hours use has different requirements from an ecommerce platform taking orders around the clock or a portal supporting daily operations.
Google's guidance on service level objectives makes a useful broader point: reliability targets should support decisions, and aiming for 100% is neither realistic nor automatically worthwhile. Each additional nine normally requires more redundancy, monitoring, operational discipline and expense.
A sensible target begins with the customer and business impact. Identify which journeys must work, when they matter most, how much interruption is tolerable and which external services could undermine the experience. Then align the hosting, monitoring and support arrangements with those answers.
The most revealing hosting question is not simply, "What uptime percentage is promised?" It is, "What does that promise cover, how will we know when a customer journey fails, and who is responsible for restoring it?" That turns a polished number into a practical reliability decision.
