Three nines sounds like a commitment. A "99.9% uptime guarantee" appears on practically every VPS provider's pricing page, and most buyers read it as a meaningful promise. In practice, the gap between what the marketing copy says and what the service level agreement actually delivers can be considerable. Understanding why requires a closer look at how providers define, measure, and calculate uptime.
The Arithmetic Behind the Guarantee
Start with the math, because the math surprises most people.
| Uptime SLA | Downtime allowed per year | Downtime allowed per month |
|---|---|---|
| 99.9% | 8 hours 46 minutes | 43 minutes |
| 99.95% | 4 hours 23 minutes | 22 minutes |
| 99.99% | 52 minutes | 4 minutes |
| 99.999% | 5 minutes | 26 seconds |
Calculated using 365 days per year and 30-day months. Figures rounded to the nearest minute.
A 99.9% commitment permits nearly nine hours of downtime over 12 months. That might still look acceptable at first glance. It becomes considerably less reassuring once you understand that most SLA documents are structured in ways that make the effective allowed downtime substantially higher than the headline percentage implies.
Two aspects of how the figure is applied are worth understanding. First, some providers calculate against a monthly window, resetting the clock each billing period, while others use a rolling 12-month average. The measurement window changes how credits are triggered when a bad month occurs. Second, a 99.9% monthly SLA permits 43 minutes of downtime per month. If a provider operates right at that threshold every single month, the cumulative total over a year exceeds eight hours, which is the same figure the annual table shows but arriving via a different contract structure.
What Counts as "Downtime" in an SLA
Providers do not define downtime simply as "the server is unreachable." SLA agreements typically contain a definition section listing what the guarantee covers and, more importantly, what it excludes. Common exclusions include:
- Scheduled maintenance windows (often several hours per month)
- Denial-of-service attacks targeting your server
- Failures in third-party services, such as upstream carriers or DNS providers
- Interruptions caused by software or configurations you installed or changed
- Outages that fall below a minimum continuous duration threshold (commonly one to five minutes)
The last point deserves particular attention. If a provider defines a qualifying outage as "continuous unavailability exceeding five minutes," then a four-minute interruption does not count against the SLA regardless of what it cost you. Short, recurring disruptions can accumulate to dozens of minutes per month without ever triggering a formal incident under the contract.
Read the definition section before reading the percentage. The percentage alone is close to meaningless without it.
Scheduled Maintenance: The Largest Asterisk
Most VPS providers reserve the right to take infrastructure offline for planned maintenance without that time counting against their uptime commitment. The permitted window size varies across providers, but reservations in the range of one to four hours per calendar month are common in the industry. The exact terms are always in the SLA document.
This is not unreasonable in principle. Infrastructure requires OS patching, hardware replacement, and hypervisor updates. Brief, announced restarts are a normal part of operating a hosting platform.
The issue is that scheduled maintenance is typically excluded from uptime calculations entirely, rather than deducted from the SLA figure. A provider with a four-hour monthly maintenance window and a 99.9% SLA can take the server offline for four hours (uncontested, without applying any downtime credit) and then have an additional 43 minutes of permitted unplanned downtime on top of that. The combined total is well over four hours per month of permissible unavailability, while the marketing page continues to display "99.9% uptime."
Check whether maintenance windows are excluded and how large those windows are permitted to be. This is often a more meaningful number than the SLA percentage itself.
Who Measures Uptime and How
The methodology matters as much as the metric.
VPS providers typically measure uptime using their own internal monitoring. The same company that benefits commercially from a strong uptime record is also deciding what constitutes a qualifying incident. This arrangement does not mean providers falsify their numbers, but it does mean independent verification is worth seeking out.
What the monitoring actually measures is not always specified clearly:
- Network reachability: Is the host responding at the network layer? Common and easy to implement, but it does not confirm that your application is actually serving traffic.
- Service-level availability: Is a specific port or protocol responding? More practically useful, but requires monitoring at your specific endpoint.
- Response time thresholds: Many monitoring systems only register an incident after a service has been unreachable for a consecutive window, often one to five minutes. Brief outages or flaps may never be recorded.
Some providers operate public status pages that log historical incidents. Having a transparent record that shows actual past outages, including when they started, when they were resolved, and what caused them, is a more credible signal than a static "all systems operational" page. A provider willing to publish its incident history openly is giving you the data you actually need to evaluate reliability.
Independent third-party monitoring is the most objective source. A growing number of VPS users run continuous uptime checks from external services. When those users write reviews, they share actual monitoring data. That real-world operational view is frequently more useful than anything in a provider's own SLA document.
SLA Credits: What You Actually Receive
Read the compensation section carefully. The typical structure works as follows:
- If uptime falls below the SLA threshold in a given period, you may be eligible for a service credit. Credits are typically calculated as a multiple of the downtime duration, and one to ten times the affected hours is a common range across the industry. The payout takes the form of a billing credit, not a cash refund.
- Credits are usually capped at a percentage of the affected period's fee, often between 50% and 100%
- You are typically required to file a claim within a specified window after the incident, often between 24 and 72 hours
- Credits apply to future invoices, not cash refunds
For an entry-level VPS plan billed at a typical monthly rate, a 100% credit covers at most a fraction of what a significant production outage costs in lost transactions, missed orders, or customer support time. The credit is acknowledgement that something went wrong. It is not compensation for business impact.
This does not make SLAs worthless. An SLA creates accountability, gives you a basis for comparing providers, and establishes a documented commitment. The point is that evaluating providers purely on headline uptime percentage misses most of what actually matters.
What to Verify Before Choosing a Provider
Rather than taking a provider's uptime claim at face value, check these things directly before committing:
-
Find the actual SLA document. Not the feature list. Not the FAQ. The contractual terms. What is excluded? What duration must an outage reach before it qualifies? How are credits calculated and capped?
-
Look for a public status page with incident history. Real operational data, including past incidents, is more informative than a current-status dashboard. If the only page available shows today's green status with no history, you have no objective track record to evaluate.
-
Search user reviews for reliability observations. Providers with poor uptime track records generate specific reviewer feedback: delayed maintenance notifications, repeated short outages, slow incident response. Browse user reviews on VPS Host Review filtered by the provider you are evaluating. Reports from operators running actual workloads for months at a time are more useful than any SLA figure.
-
Understand the measurement window. Monthly SLAs reset each billing cycle. Annual SLAs allow downtime to accumulate across 12 months. A provider can have a dismal month while remaining technically compliant as long as the annual average stays above the threshold.
-
Ask what the maximum credit can be. If the cap is one month's service fee, that is the provider's complete contractual exposure regardless of how long your application was inaccessible. Understanding the cap tells you how much the guarantee is actually worth to your business.
The Reliability Score on This Site
Every provider reviewed on VPS Host Review is rated by users across six categories, one of which is Reliability. This score reflects real-world uptime and incident experience reported by people who have run workloads on those servers, not the provider's own marketing claims. A Reliability score built from a substantial number of independent reviews carries more weight than a marketing PDF claiming five nines with no user verification behind it.
If uptime is a hard requirement for your application, the Reliability category is the first thing to examine when comparing providers. Start with the providers directory to compare reliability scores, or browse recent user reviews from operators who have tested these platforms in production.
For a broader look at how reliability fits alongside pricing, performance, support, ease of use, and value for money in a complete provider evaluation, the practical evaluation guide covers all six scoring dimensions in detail.
One Number Is Not Enough
A provider promising 99.9% uptime is not making a dishonest claim. That number is mathematically accurate. What it permits, what it excludes, and how it is measured is where the real picture lives.
Read what counts as downtime. Check what is excluded. Understand how credits are filed and what the maximum payout is. Then look at what actual users operating workloads on that platform have reported over time. The history is more useful than the headline.