"99.9% uptime guaranteed" sounds reassuring until you realize almost nobody reads far enough to see what happens when that guarantee is broken, or what counts as breaking it in the first place. An SLA (Service Level Agreement) is a specific, contractual document — the uptime percentage is just the headline number, and the actual value of the guarantee lives in the definitions, exclusions, and credit process buried in the fine print below it.
Uptime Percentages, Translated Into Actual Minutes
The gap between 99% and 99.99% looks small on paper but is enormous in practice:
| Uptime % | Downtime per Month | Downtime per Year |
|---|---|---|
| 99% | ~7.3 hours | ~3.65 days |
| 99.9% | ~43.8 minutes | ~8.76 hours |
| 99.95% | ~21.9 minutes | ~4.38 hours |
| 99.99% | ~4.4 minutes | ~52.6 minutes |
| 99.999% | ~26 seconds | ~5.26 minutes |
99.9% is a realistic, commonly offered target for a well-run single dedicated server. Anything at 99.99% or above generally implies architectural redundancy (multiple servers, load balancing, automated failover) — a single physical server, no matter how well maintained, has a hardware failure mode that a redundancy-based architecture is specifically designed around.
What Actually Counts as "Downtime" in Most SLAs
This is where most of the real value (or lack of it) in an SLA lives. Carefully check whether the following are counted as qualifying downtime or explicitly excluded:
- Scheduled/announced maintenance windows — almost universally excluded from uptime calculations
- Network issues outside the provider's own network (upstream internet backbone problems) — frequently excluded
- DDoS attacks — sometimes excluded entirely, sometimes covered only above a certain mitigation-capacity threshold
- Issues caused by the customer's own configuration, software, or a customer-initiated reboot — always excluded
- Force majeure events (natural disasters, widespread power grid failure) — always excluded
An SLA that reads "99.9% uptime guaranteed" but excludes scheduled maintenance, DDoS-related downtime, and anything network-related outside the immediate rack can end up covering a much narrower set of failure scenarios than the headline number implies.
What You Actually Get When an SLA Is Breached
Virtually no hosting SLA in the industry offers cash refunds for downtime — the near-universal remedy is service credit, typically a percentage of that month's hosting fee applied to a future invoice.
| Downtime in Month (Typical Tiered Structure) | Typical Credit |
|---|---|
| Below the guaranteed threshold | No credit owed |
| Just over threshold (e.g. up to 1 hour extra) | 5-10% of monthly fee |
| Significantly over threshold (multiple hours) | 25-50% of monthly fee |
| Extended outage (many hours to a full day) | 100% of monthly fee, rarely more |
Read that carefully: the maximum a typical SLA credit will ever return you is the cost of that month's hosting — never compensation for lost business revenue, lost customers, or reputational damage from the outage itself. An SLA is a service-quality commitment and a modest financial acknowledgment, not business interruption insurance.
How to Actually File and Win an SLA Claim
- Keep your own independent uptime log — see our monitoring guide — since you will need timestamped proof, and relying solely on the provider's own status page is a conflict of interest
- File the claim within the window specified in the SLA (often 5-30 days after the incident) — miss this window and most providers will decline the claim regardless of merit
- Reference the specific outage window with start/end times and any correlating support ticket numbers
- Understand which exclusions might apply before assuming a full credit is owed — a partial network issue during a DDoS event may fall under an exclusion clause
SLA Comparison: What "Good" Looks Like
| SLA Element | Weak SLA | Strong SLA |
|---|---|---|
| Uptime guarantee | Vague "best effort" or unstated | Specific percentage, clearly defined |
| Downtime definition | Undefined or ambiguous | Explicitly defined, minimal broad exclusions |
| Credit process | Unclear or requires excessive proof burden | Simple, clearly documented claim process with a real window |
| Hardware replacement guarantee | Not mentioned | Specific replacement time commitment (e.g. failed disk replaced within X hours) |
| Network uptime vs power uptime vs hardware uptime | Bundled vaguely as "uptime" | Broken out separately with distinct guarantees |
Beyond Uptime: Other SLA Components Worth Checking
- Hardware replacement time guarantee (how fast a failed drive, RAM stick, or PSU gets physically replaced)
- Network uptime guarantee, separate from server/hardware uptime
- Support response time guarantee (time to first response on a critical ticket, not just resolution time)
- Data center power and cooling guarantees, particularly relevant if you are colocating your own hardware
Buyer's Checklist
- Read the actual downtime definition and exclusion list, not just the headline percentage
- Confirm the claim window and required documentation before you need to file one under pressure
- Check whether DDoS-related downtime is covered or excluded, given how common DDoS attacks are
- Ask about hardware replacement time commitments specifically, separate from the general uptime number
- Understand that the maximum realistic outcome of any SLA claim is a partial-to-full credit, not compensation for lost revenue
Frequently Asked Questions
What SLA uptime percentage should I look for?
99.9% is a solid, realistic standard for a single dedicated server; treat anything promising 99.99%+ on a single non-redundant server with healthy skepticism.
Do SLA credits cover lost business from downtime?
No — virtually all hosting SLAs cap remedies at a service credit against hosting fees, not compensation for lost revenue, customers, or reputation.
Is scheduled maintenance counted against the uptime guarantee?
Almost never — scheduled, properly announced maintenance windows are standard exclusions in nearly every hosting SLA in the industry.
How do I prove downtime happened if my provider disputes it?
Independent third-party monitoring logs (UptimeRobot, Pingdom, or your own external monitoring setup) with timestamps are the strongest evidence, since they are not reliant on the provider's own reporting.
Does a managed dedicated server come with a better SLA than unmanaged?
Often yes — managed plans frequently bundle faster support response guarantees and sometimes higher uptime commitments, since the provider carries more operational responsibility.
What happens if my server goes down due to a DDoS attack?
This depends entirely on the specific exclusion language in your SLA — some providers exclude DDoS-related downtime outright, others cover it above a certain mitigation capacity threshold. Check explicitly rather than assuming.
WebsNP's dedicated server SLA is written in plain language with a clearly defined credit process, not buried in ambiguous exclusions. Review our dedicated server plans or contact us with SLA questions before you sign a contract.