VPS Uptime Explained

Provider uptime SLAs measure the availability of the underlying infrastructure: is the virtual machine running, is it reachable via the network, is the hypervisor functioning. This is a narrow slice of what 'the service is up' means to users. A VPS can be running and reachable while the web server has crashed, the database has run out of connections, or a misconfigured deployment has broken the application. These failures are invisible to the provider's uptime monitoring and irrelevant to SLA calculations.

The uptime percentage describes a year's worth of acceptable downtime, not a guarantee of zero outages in any given month. 99.9% permits 8.7 hours of downtime per year — roughly 43 minutes per month. 99.99% permits 52 minutes per year. These windows can be consumed in a single event. An SLA measured at 99.9% annually is compatible with a single four-hour outage.

Most provider SLAs define uptime as the percentage of time the server passes a network reachability check — typically an ICMP ping or a TCP connection test to a specific port. The check runs at regular intervals, often every minute or every five minutes. Downtime is counted only when the check fails continuously for a defined minimum period, which means brief outages of less than the check interval may not count against the SLA at all.

SLA remediation is almost universally credits, not refunds. When a provider misses its uptime guarantee, the user receives credit toward future service — typically a fraction of the monthly fee for the hours affected. The credit does not compensate for business impact from the outage. A one-hour outage during peak traffic that costs the user several times the monthly hosting fee earns a credit that covers a fraction of the monthly fee. The SLA is a service commitment, not an insurance policy.

Scheduled maintenance is typically excluded from SLA calculations. Providers reserve the right to take infrastructure offline for maintenance during defined windows. How much notice they provide, how long those windows last, and how they schedule them relative to the user's peak traffic hours varies significantly by provider and matters for applications with predictable high-traffic periods.

Network degradation short of complete outage is not covered by most uptime SLAs. A server that is reachable but experiencing 40% packet loss, or responding in 10 seconds instead of 100 milliseconds, passes the reachability check and does not count as downtime. From the user's perspective, the application is broken. From the provider's SLA perspective, the server is up.

Application-layer failures are entirely outside the SLA. A crashed application process, a full disk that's stopped the database, a misconfigured firewall rule that blocks user traffic — these are the user's infrastructure problems on an unmanaged VPS. The provider's SLA is silent on them because they aren't the provider's responsibility to prevent or remediate.

Moving from 99.9% to 99.99% in the SLA represents a tenfold reduction in permitted downtime. What it practically represents depends on what causes downtime at a given provider. If downtime at a provider is rare and brief, the difference between 99.9% and 99.99% is hypothetical — both perform well in practice. If downtime at a provider is frequent and correlated with maintenance windows, the higher SLA represents a genuine commitment to either better infrastructure or better maintenance practices.

High-availability architecture — load-balanced instances across multiple availability zones or regions — produces application uptime that exceeds any single server's SLA because the application survives individual server failures. This is a more reliable path to application availability than a higher-SLA single server, because the availability of the application stops depending on the availability of any single piece of infrastructure. The cost is higher. The operational complexity is higher. The actual uptime achievable is also higher.

For most single-server VPS deployments, the practical uptime ceiling is the provider's infrastructure reliability minus the user's own failure modes. The user's application crashes, the disk fills, the deployment breaks things — these consume far more availability than provider SLA violations at reliable providers. Improving the user-owned failure modes often produces more uptime improvement than moving to a higher-SLA provider.