A VPS uptime SLA is a provider’s contractual commitment to keep a defined service available for a stated percentage of a measurement period. It also explains what counts as downtime, which events are excluded, how availability is calculated, and what remedy applies if the commitment is missed. A 99.9% SLA does not promise zero outages or guarantee that your application will be available 99.9% of the time. It is a conditional service commitment that must be read together with its definitions, exclusions, claim process, and service-credit table.
For buyers, the practical question is not simply, “Does this VPS have a 99.9% uptime guarantee?” It is, “What exactly is covered, how much downtime can occur, which failures do not count, and is the remedy meaningful for my workload?”
What an uptime SLA actually guarantees
An uptime percentage becomes useful only when four parts are clear:
- Scope: Which product, region, instance, API, console, network path, or supporting service is covered?
- Measurement: Is availability measured by time, successful requests, individual instances, or an aggregated service pool?
- Conditions and exclusions: Which maintenance events, customer actions, attacks, external network failures, or unsupported configurations are removed from the calculation?
- Remedy: What service credit is available, how is it calculated, and how must the customer claim it?
The SLA therefore describes a minimum contractual commitment rather than a complete reliability design. Your VPS can remain technically online while your application is unavailable because of a failed deployment, full disk, database error, firewall rule, expired certificate, or overloaded process. Those application-layer failures may be your operational responsibility rather than provider downtime.
This distinction matters when comparing a low-cost plan with a more dependable service. The percentage on a pricing page is only the beginning. The detailed terms determine the commitment’s real value.
What 99.9% uptime means in real time
Availability is commonly calculated with this formula:
Availability percentage = (total measured time - counted downtime) / total measured time × 100
Using a 30-day month as a simple reference, the percentages translate into the following approximate maximum downtime:
| Availability | Approximate downtime per 30-day month | Approximate downtime per year |
|---|---|---|
| 99% | 7 hours 12 minutes | 3 days 15 hours 36 minutes |
| 99.9% | 43 minutes 12 seconds | 8 hours 45 minutes 36 seconds |
| 99.95% | 21 minutes 36 seconds | 4 hours 22 minutes 48 seconds |
| 99.99% | 4 minutes 19 seconds | 52 minutes 34 seconds |
| 99.999% | 25.9 seconds | 5 minutes 15 seconds |
These figures are mathematical reference points, not universal credit thresholds. A 31-day month gives a 99.9% allowance of about 44 minutes 38 seconds, while a 28-day month gives about 40 minutes 19 seconds. More importantly, the SLA may exclude maintenance or require an outage to meet a specific definition before any minute is counted.
Measurement periods cannot usually be mixed. If an SLA is measured monthly, a perfect month does not normally “bank” availability for a later month. Likewise, the annual figure does not mean one long outage automatically qualifies for a credit if the provider’s contract calculates each billing month separately.
Read the measurement definition before the headline
Two providers can both advertise 99.9% while offering materially different coverage. Review the following details before comparing the percentages.
What is considered unavailable?
Some SLAs count only complete inaccessibility. Others measure failed requests, API responses, regional service availability, or the health of a group of instances. Slow performance, packet loss, intermittent errors, or the failure of one feature may not qualify unless the definition explicitly includes them.
A definition can also include a minimum duration. For example, an outage may need to continue for several consecutive minutes before it becomes counted downtime. Several shorter interruptions could affect users without crossing that contractual threshold.
What is the measurement scope?
Determine whether the percentage applies to:
- one individual VPS;
- all instances in an account;
- a specific region;
- the compute service only;
- attached storage, backups, networking, console access, and APIs separately;
- or a broader platform aggregate.
A compute SLA does not automatically cover every dependency. If your VM is available but a customer-managed database process has stopped, the compute commitment may still be met. Similarly, a snapshot or backup product may have its own terms.
Who provides the authoritative data?
Your monitoring is essential for understanding user impact, but an SLA may specify that the provider’s own telemetry is authoritative for credit calculations. That creates two legitimate but different records:
- Operational evidence: what your users and external monitors experienced;
- Contractual evidence: what the SLA’s defined measurement system recorded.
Keep your own timestamps, error logs, support conversations, and affected-resource details even when the provider controls the final calculation. They help you diagnose the incident and submit a complete claim.
Credits are a billing remedy, not downtime compensation
Service credits usually reduce future charges for the affected service. They are not the same as compensation for lost revenue, customer churn, staff time, missed transactions, or reputational damage.
Suppose a VPS costs $20 per month and the applicable credit is 10%. The remedy may be $2 in future service credit even if the outage caused a much larger business loss. This does not make the SLA useless. It means the SLA should be treated as:
- evidence of the provider’s minimum commitment;
- a defined accountability mechanism;
- one input into risk and architecture decisions;
- not an insurance policy for the business impact of downtime.
Read whether credits are automatic or claim-based. Many providers require the customer to open a support request, provide incident details, and file within a limited window. Missing the deadline can remove eligibility even when the outage was real.
Also check the credit cap, expiration rules, minimum credit amount, eligible service charges, and whether the credit can be refunded or transferred. A generous percentage can still have limited value when it applies only to a small portion of the monthly bill.
Exclusions determine the practical value
The exclusions section often matters as much as the headline percentage. Common categories include:
- announced scheduled maintenance;
- emergency maintenance;
- customer configuration errors;
- customer-installed software and operating-system failures;
- resource exhaustion caused by the workload;
- malicious traffic or distributed denial-of-service events;
- internet or third-party failures outside the provider’s control;
- force majeure events;
- suspended, overdue, abusive, or non-compliant accounts;
- unsupported, preview, or incorrectly configured services.
Exclusions are not automatically unreasonable. A provider cannot credibly guarantee every application, third-party network, or customer action. The buyer’s job is to identify which excluded risks still threaten the workload and decide who will control them.
For example, an SLA may exclude a broken application deployment. You can reduce that risk with tested releases and rollback procedures. It may exclude customer firewall mistakes. You can reduce that risk with change review and configuration backups. It may exclude a single-server application failure even when the underlying VM remains healthy. You can reduce that risk with process supervision, health checks, backups, and—where justified—redundant architecture.
The uptime SLA decision framework
Use the SLA as a structured buying input rather than a single score.
| Decision area | Question to ask | Why it matters |
|---|---|---|
| Business impact | What happens after 5, 20, or 45 minutes of outage? | Determines whether 99.9% is operationally acceptable. |
| Covered service | Does the commitment cover compute only or also storage, networking, backups, and APIs? | Reveals uncovered dependencies. |
| Downtime definition | Does degradation count, or only complete inaccessibility? | Affects whether user-visible incidents qualify. |
| Measurement window | Monthly, annual, per region, per instance, or aggregated? | Changes how outages are calculated. |
| Exclusions | Which likely failure modes are outside the commitment? | Shows which risks remain yours. |
| Credit value | What would the actual credit be at your monthly spend? | Prevents treating a percentage as business-loss protection. |
| Claim process | What evidence and deadline are required? | Determines whether the remedy is realistically usable. |
| Recovery design | Can the workload recover without waiting for a credit decision? | Reliability depends on operations and architecture, not only contract terms. |
A simple buyer rule is to compare the allowed counted downtime with the maximum tolerable user impact. If the workload cannot tolerate the contract’s implied downtime—or important incidents are excluded—the solution requires additional resilience rather than a more optimistic interpretation of the percentage.
When to choose / when not to choose
Choose a VPS with a 99.9% monthly SLA when the workload can tolerate roughly 43 minutes of counted provider-layer downtime in a 30-day month, the exclusions are acceptable, and your team has a practical recovery path for application-level failures. This can be appropriate for many company websites, internal tools, development environments, staging systems, small SaaS products, and business applications with clear backups and operational ownership.
Do not choose a provider solely because its headline percentage is higher. A 99.99% claim with narrow definitions, broad exclusions, weak support, or no meaningful remedy may be less useful than a clearly documented 99.9% commitment. You should also avoid treating a single-VM SLA as sufficient for a workload that requires near-continuous availability. In that case, evaluate application redundancy, load balancing, database resilience, backup recovery, and failure isolation separately.
A higher SLA is most valuable when its scope and definitions match the service your users actually depend on. It is less valuable when the application has many uncontrolled single points of failure above the infrastructure layer.
How the wrong choice shows up in practice
The wrong interpretation usually appears after the first serious incident. The buyer expects a full refund, but the SLA offers a small future credit. The application was unreachable, but the VM remained online, so the incident does not meet the downtime definition. An external monitor detected several interruptions, but each was shorter than the minimum counted interval. A claim is rejected because it was filed after the deadline or lacked timestamps. Or the provider meets its compute commitment while a customer-managed database, DNS record, or deployment failure keeps the application offline.
These outcomes are rarely solved by debating the percentage after the event. They are prevented by reading the terms before purchase and assigning responsibility for every failure layer.
SLA, SLO, monitoring, and high availability are different
These concepts support one another but should not be merged:
- SLA: the provider’s contractual commitment and remedy.
- SLO: the reliability target your team sets for the workload.
- Monitoring: the system that detects and records actual behavior.
- High availability: an architecture designed to keep serving users when components fail.
- Disaster recovery: the process for restoring service and data after a severe disruption.
An SLA can inform your internal target, but it does not create the target for you. Monitoring tells you what happened, but does not itself prevent an outage. High availability can reduce user impact, but it introduces cost and operational complexity. Disaster recovery limits the damage of major failures, but recovery time may still be longer than the SLA’s allowed downtime.
For implementation guidance, keep monitoring decisions in the cloud server monitoring guide. For architecture-level resilience, see high availability vs disaster recovery. This guide remains focused on interpreting the provider commitment.