“99.9% uptime” sounds reassuring until you do the math on what that actually allows. Hosting SLAs are one of the most misunderstood parts of a provider contract, partly because the headline number hides important details. Here is how to read one properly.
What the Percentages Actually Mean
An uptime percentage translates directly into allowed downtime over a period. The common tiers work out to roughly:
- 99% (“two nines”) — about 7 hours 18 minutes of downtime per month, or roughly 3.65 days per year.
- 99.9% (“three nines”) — about 43 minutes per month, or about 8.77 hours per year.
- 99.95% — about 21 minutes 54 seconds per month.
- 99.99% (“four nines”) — about 4 minutes 23 seconds per month, or about 52.6 minutes per year.
- 99.999% (“five nines”) — about 26 seconds per month, or about 5.26 minutes per year.
The jump from three nines to four nines is an order of magnitude tighter, and it usually requires redundant hardware, multiple network paths, and automated failover — which is why it costs more.
What Counts as Downtime (and What Doesn’t)
This is where SLAs get slippery. Read the definitions section carefully, because most SLAs exclude:
- Scheduled maintenance windows. If a provider announces maintenance in advance, that downtime usually does not count against the SLA.
- Issues outside the provider’s network. Problems with your own code, third-party services, or your local ISP are excluded.
- Force majeure. Natural disasters and similar events are typically carved out.
- Abuse or ToS violations. Downtime caused by your account being suspended does not count.
The practical question is how the provider measures uptime. Is it the server being reachable, or the service actually responding correctly? A box that pings but serves errors may technically be “up” under a narrow definition.
The Credit Structure Is the Real SLA
An SLA is only as strong as its remedy. Most hosting SLAs offer service credits, not refunds, and the credit is usually a percentage of your monthly fee, not your business losses. A typical structure might give 5% credit for dropping below the target, scaling up to a cap (often 50–100% of the monthly fee).
Two things to check: whether you have to request the credit within a time window (many require you to file a claim), and whether the credit is capped well below what an outage would actually cost you. For most customers, an SLA is a signal of confidence rather than meaningful financial protection.
Questions Worth Asking
- How is uptime measured, and is the monitoring data available to me?
- Are credits automatic, or do I have to file a claim?
- What is excluded — especially around maintenance windows?
- Is there a public status page with historical incident data?
- Does the SLA cover the network, the hardware, or both?
A Status Page Beats a Big Number
A provider that publishes a transparent, historical status page is often more trustworthy than one advertising five nines with no evidence. Past incident history tells you how a provider actually behaves under failure: how fast they detect, communicate, and recover. That track record is more useful than a contractual percentage.
Measuring Uptime Yourself: Monitoring That Catches Outages Before Customers Do
An SLA number is only useful if you can verify it, and the provider's own dashboard is not the measurement. Uptime monitoring means sending requests to your service at fixed intervals from several locations, recording the results, and alerting when checks fail. It turns "is the site up?" from a guess into a measured fact you can hold an SLA against.
Types of checks
A ping proves the host is reachable. A TCP check proves a port is listening. An HTTP check proves a page loads, and a keyword check proves the response contains what it should rather than a 200 OK error page. Monitor the user journeys that matter, not just that the machine is powered on.
Metrics beyond up or down
Track uptime percentage over the same window the SLA uses, response time, and how long detection and recovery take. Response-time trends usually warn about a memory leak or a filling disk days before the outage.
Multiple locations, tuned alerts
A single check location cannot distinguish an outage from a network problem between that location and your server. Check from several regions and require failures from more than one, or several in a row, before alerting. Route alerts to a channel the team actually watches. Alert fatigue is worse than no alerting because people stop reading.
A status page closes the loop
Publish the same checks on a public status page. It shows customers the real state of the service, cuts support load during an incident, and holds you to the same standard you hold your provider to. One-minute intervals are the norm for anything important; a NODED status page runs at noded.cloud/status.
How Noded Handles It
We are straightforward about what our SLA covers and how downtime is measured, and we would rather under-promise on paper and over-deliver in practice than advertise a number we cannot consistently hit. If you want to understand exactly what is guaranteed for a specific service, ask us and we will walk you through the terms before you commit.
FAQ
Is 99.9% uptime good?
It is fine for many workloads and allows roughly 43 minutes of downtime per month. Whether it is good enough depends on what an hour of downtime costs you. Mission-critical services usually target 99.99% or higher with redundancy.
Does scheduled maintenance count against the SLA?
Usually not, provided it falls within an announced maintenance window. This is one of the most common exclusions, so check how much maintenance the provider reserves the right to schedule.
What is the difference between uptime and availability?
They are often used interchangeably, but availability can be defined more strictly to mean the service responds correctly, not just that the server is reachable. Always check the exact definition in the contract.
Are SLA credits worth much?
They are usually a percentage of your hosting fee, not compensation for your business losses, and are often capped. Treat the SLA as a confidence signal and design your own redundancy if downtime is genuinely costly.