“99.9% uptime” looks impressive on a hosting sales page, but what does it actually mean for your website, store, or SaaS? Is that number enough for a busy e‑commerce site? How much downtime are we really talking about each month? And what happens if your provider doesn’t meet that promise—do you get real compensation, or just a nice apology?
At dchost.com we see the same pattern over and over: teams choose hosting based on a bold uptime percentage, but almost nobody reads the Service Level Agreement (SLA) behind it. Later, during a capacity planning session or a post‑incident review, someone finally opens the SLA and realizes that “99.9% uptime” doesn’t cover the kind of outage they just experienced. This article is a practical, no‑drama walkthrough of what those uptime numbers really mean in time, money, and risk. We’ll break down the math, show you what to check inside any SLA, and share how we think about uptime targets when designing hosting, VPS, dedicated server, and colocation setups for our own customers.
İçindekiler
- 1 Uptime vs Availability: What Are We Actually Measuring?
- 2 How Much Downtime Is 99.9% (and 99.99%, 99.5%) Really?
- 3 What 99.9% Uptime Usually Covers (and What It Doesn’t)
- 4 How SLA Credits Really Work (and What They Don’t Do)
- 5 How to Match Uptime Targets to Your Real Use Case
- 6 How to Independently Verify Uptime (Don’t Just Trust Marketing Pages)
- 7 Common SLA Gotchas to Watch For
- 8 Bringing It All Together: Making SLAs Work For You
Uptime vs Availability: What Are We Actually Measuring?
Before diving into 99.9% and friends, it helps to be clear on a few basic terms. In SLAs, providers often use “uptime” and “availability” almost interchangeably—but technically they’re not always the same thing.
Uptime
Uptime is the percentage of time a given component or service is up and reachable during a defined period (usually a calendar month). For a hosting SLA, that might be:
- The power and cooling in a data center
- The core network (routers, switches, uplinks)
- The hypervisor layer for VPS hosting
- A specific shared hosting platform or cluster
If you want a broader primer on the concept itself, we have a separate article explaining what uptime is and how to ensure continuous availability for websites.
Availability
Availability is more about the end result: can users actually complete what they came to do? Your host’s infrastructure might be 100% up, but your site can still be effectively down because:
- Your application has a bug
- Your database is locked or overloaded
- Your DNS is misconfigured
- You deployed a bad release
Most hosting SLAs only cover the layers the provider directly manages. If the SLA says “network uptime,” then an application crash on your VPS usually doesn’t count as downtime for SLA purposes—even if your users see a blank page.
How Much Downtime Is 99.9% (and 99.99%, 99.5%) Really?
Percentages feel abstract. Minutes and hours don’t. Let’s translate the typical SLA numbers into real downtime.
| Uptime % | Max downtime per month | Max downtime per year |
|---|---|---|
| 99% | ~7 hours 18 minutes | ~3 days 15 hours 36 minutes |
| 99.5% | ~3 hours 39 minutes | ~1 day 19 hours 48 minutes |
| 99.9% | ~43 minutes 50 seconds | ~8 hours 45 minutes |
| 99.95% | ~21 minutes 54 seconds | ~4 hours 23 minutes |
| 99.99% | ~4 minutes 23 seconds | ~52 minutes 34 seconds |
| 99.999% | ~26 seconds | ~5 minutes 15 seconds |
These numbers assume a 30‑day month. Real SLAs sometimes calculate monthly uptime slightly differently, but this is a good mental model.
Why the Difference Between 99.9% and 99.99% Is Huge
The jump from 99.9% to 99.99% is only 0.09 percentage points on paper, but it cuts your allowed downtime by about 10x—from roughly 44 minutes to roughly 4 minutes per month.
That’s the difference between:
- Being able to survive a single 30–40 minute outage in a month without violating SLA
- Needing your entire stack to recover from issues in under 4–5 minutes, or to fail over automatically to another region or data center
Understanding that gap is critical when you’re planning uptime targets for online stores, payment systems, and APIs that can’t afford long outages.
What 99.9% Uptime Usually Covers (and What It Doesn’t)
When a hosting provider writes “99.9% uptime” on the homepage, the details live in the SLA. Here’s what you should look for inside the document.
1. Scope: Which Components Are Included?
Common categories in a hosting SLA include:
- Network uptime: The provider’s backbone, routers, switches, and upstream connectivity
- Power uptime: Data center electrical infrastructure, UPS, generators
- Host node / hypervisor uptime: For VPS and cloud servers
- Platform uptime: For managed services like shared hosting or a managed WordPress platform
Pay attention to whether the 99.9% number applies to:
- Just the network, or
- Network + power + hypervisor (for VPS), or
- The full hosting platform your site lives on
At dchost.com, for example, we think of uptime at different layers when designing infrastructure—because a rock‑solid network is pointless if the storage tier is a single point of failure.
2. Measurement Window and Formula
Most SLAs define uptime over a calendar month, but the exact formula matters. A common approach is:
Uptime % = (Total minutes in month − Unplanned downtime minutes) / Total minutes in month × 100
Watch for clauses that exclude specific types of downtime from the calculation, such as:
- Scheduled maintenance
- Emergency security patches
- Force majeure (natural disasters, large‑scale internet issues)
- Customer‑caused incidents (misconfiguration, DDoS from your own exposed app, etc.)
For a deeper dive into threats that can impact availability, you might find our article on the rise in DDoS attacks targeting hosting providers useful—it shows why many SLAs handle some attack scenarios differently.
3. What Counts as Downtime?
This is where many surprises hide. Some key points to check:
- Partial outages: Does high packet loss (for example 50%) count, or only complete loss of connectivity?
- Performance issues: If your site is technically up but takes 30 seconds to load, does that count as downtime?
- Component failures: If a single disk or node in a cluster fails but the platform automatically fails over, does it count as downtime?
- Security incidents: If your server is taken offline to contain malware, is that considered downtime under the SLA?
In practice, most SLAs define downtime as a complete loss of connectivity or “unavailability” measured from the provider’s monitoring systems, not from your specific user base or region.
4. Scheduled Maintenance and Emergency Work
Almost all providers reserve the right to perform scheduled maintenance. You’ll usually see language like:
- Maintenance windows must be announced X hours or days in advance
- Maintenance is excluded from uptime calculations
- The provider will try to minimize impact
For critical workloads, it’s worth asking:
- Do you have redundant instances in another region or data center?
- Can you route traffic away during maintenance using DNS?
- Have you tested failover recently?
Our guide on Anycast DNS and automatic failover walks through how DNS‑level strategies can help you ride out maintenance and localized outages more gracefully.
How SLA Credits Really Work (and What They Don’t Do)
Most hosting SLAs don’t promise cash refunds; they promise service credits. Understanding how those credits are calculated (and when you can claim them) is just as important as the uptime percentage itself.
Typical Credit Structure
A simplified example of a credit table for a 99.9% uptime SLA might look like this:
- Uptime 99.9% – 100%: no credit
- 99.0% – 99.89%: credit equal to 10% of the monthly fee
- 95.0% – 98.99%: credit equal to 25% of the monthly fee
- Below 95%: credit equal to 50% (or sometimes more) of the monthly fee
Important details to verify:
- Maximum credit cap: Many SLAs cap credits at 100% of your monthly payment, no matter how bad the outage
- Service scope: Credits usually apply only to the affected service, not your entire account
- Non‑transferable: Credits often cannot be refunded in cash or transferred
You Must Often Open a Ticket to Claim Credits
In many SLAs, credits are not automatic. You typically need to:
- Open a support ticket within a certain time window (for example 7–30 days after the incident)
- Provide details of the outage (date, time, impacted services)
- Wait for the provider to verify the downtime against their logs
If you don’t follow the formal process, you may lose the right to credits—even if the provider clearly missed the SLA target. That’s why it’s useful to have your own monitoring and incident notes.
Credits Don’t Cover Your Business Losses
This part is often misunderstood. SLA credits compensate you for the hosting fee you paid, not for:
- Lost sales during downtime
- Reputation damage
- Penalties in your own client contracts
- Operational costs for remediation
If you’re paying, say, $50/month for a VPS and qualify for a 50% credit after a bad outage, you’re getting $25 back. For many online businesses, a one‑hour outage during peak hours can cost far more than that. This is why we always emphasize: an SLA is not business continuity. It’s one piece of your overall resilience strategy, alongside backups, DR planning, and redundancy.
If you want to think beyond “just uptime” and into recovery objectives and disaster planning, our article on writing a no‑drama disaster recovery plan (RTO/RPO, backup tests, and runbooks) is a good next step.
How to Match Uptime Targets to Your Real Use Case
Not every project needs five nines. Conversely, some workloads are too critical to live on a single, non‑redundant server even if the SLA says 99.99%. Here’s how we think about it with customers.
Step 1: Identify How Bad Downtime Really Is (Per Hour)
Try to put a rough value on:
- Lost revenue per hour of downtime (average and peak)
- Operational impact (support tickets, manual workarounds)
- Reputation and SEO impact for repeated outages
Even a rough calculation is better than guessing. A small personal blog and a high‑volume e‑commerce site clearly don’t have the same risk profile.
Step 2: Choose an Uptime Band That Fits
Very roughly, you can think in these bands:
- “Good enough” (around 99.5% – 99.9%): Personal sites, internal tools, early‑stage MVPs
- “Business‑critical” (99.9% – 99.95%): Standard e‑commerce stores, SaaS dashboards, customer‑facing portals
- “Highly critical” (99.99% and above): Payment systems, logistics and booking platforms, applications with contractual uptime obligations
Remember: the SLA level from your hosting provider is the infrastructure baseline. Your real end‑to‑end availability will be lower once you factor in deployments, application bugs, and third‑party dependencies.
Step 3: Design for Redundancy, Not Just a Bigger Server
Once your uptime target is clear, the architecture conversation becomes much easier:
- For simpler projects, a well‑sized shared hosting, VPS, or single dedicated server with backups and monitoring might be sufficient
- For higher availability, you add layers: multiple VPS nodes behind a load balancer, replicated databases, and multi‑region DNS failover
- For mission‑critical workloads, you combine redundant infrastructure with offsite backups, tested DR plans, and stricter deployment practices
dchost.com provides shared hosting, VPS, dedicated servers, and colocation precisely so you can choose the right building blocks for your target uptime. The SLA is one input; the architecture you build on top is just as important.
How to Independently Verify Uptime (Don’t Just Trust Marketing Pages)
Relying solely on your provider’s status page or SLA metrics is risky. For serious projects, we always recommend setting up your own monitoring.
External Uptime Monitoring
External monitors simulate user requests from outside the provider’s network. They can:
- Ping your server or send HTTP/HTTPS requests to your site
- Alert you by email, SMS, or chat when your site is down
- Generate uptime reports you can compare to SLA promises
Use multiple locations if possible; this helps you distinguish between local ISP issues and real server‑side downtime.
Internal Server Monitoring
External uptime checks tell you “up or down”; internal metrics tell you why. On VPS, dedicated servers, or colocated hardware, we like to see at least:
- CPU, RAM, disk IO, and network usage
- Filesystem usage and inode counts
- Web server and database health (latency, errors, connection counts)
- SSL certificate expiry and DNS health
If you want to go deeper on this side, we’ve documented a practical stack in our article on VPS monitoring and alerts with Prometheus, Grafana, and Uptime Kuma. Even if you don’t copy that setup exactly, it shows how to combine external and internal checks in a way that maps nicely to uptime SLAs.
Logging and Incident Notes
When something does go wrong, detailed logs and timestamps are invaluable:
- They help you debug faster
- They provide evidence if you need to request SLA credits
- They feed into post‑incident reviews and architecture improvements
Over time, you’ll see patterns: specific times of day, recurring error types, or resource exhaustion that suggests it’s time to upgrade from shared hosting to a VPS, from a single VPS to a cluster, or from one data center to a more resilient multi‑region design.
Common SLA Gotchas to Watch For
Let’s summarize some of the patterns we see teams trip over when evaluating “99.9% uptime” promises.
Gotcha 1: Uptime Applies Only to the Network, Not the Service
Some SLAs advertise a big uptime number but scope it only to network connectivity. If the shared hosting platform, storage system, or control panel has issues, you might still be out of luck for credits because the core network stayed up.
Gotcha 2: Narrow Definition of Downtime
If downtime is defined as a complete loss of connectivity, then:
- Severe packet loss
- 30‑second timeouts
- Regional routing problems
might not count as downtime—even though your users can’t realistically use your site. Read that section of the SLA twice.
Gotcha 3: Excluding DDoS and Security Incidents
Many SLAs carve out exceptions for attacks and security issues. With the rise in cybersecurity threats and DDoS attacks, this matters more every year. If your site is taken offline in a mitigation effort, will that downtime be excluded from SLA calculations?
Gotcha 4: You Must Detect and Report Issues Yourself
Some providers only recognize downtime from their own monitoring systems. If your monitoring shows a 60‑minute outage but their system shows 20 minutes of degraded performance, you may get a smaller credit than you expected. This is another reason to keep your own logs and monitoring traces.
Gotcha 5: No Business‑Level Guarantee
Remember that SLAs are usually offered on a best‑effort infrastructure level. They are not a guarantee that your overall business will meet a certain availability target. To get end‑to‑end guarantees, you’d typically need:
- Redundant hosting (VPS or dedicated) across multiple availability zones or data centers
- Robust DNS strategies like Anycast and failover
- Solid backup and recovery workflows
- Clean 3‑2‑1 backup strategies with offsite copies
The SLA is a foundation, not the whole house.
Bringing It All Together: Making SLAs Work For You
Uptime numbers like 99.9% look simple, but as you’ve seen, the story behind them is more nuanced. A good SLA will tell you three things clearly: what’s covered, how it’s measured, and what happens if the promise is not met. Your job is to connect those details to your real‑world risks, architecture, and business priorities.
At dchost.com, we design our hosting, VPS, dedicated server, and colocation offerings with that bigger picture in mind. The SLA is one layer; on top of it we encourage customers to add sensible monitoring, tested backups, and—when it makes sense—redundant setups that can survive node, rack, or even data center failures. If you’re not sure what level of uptime you really need, or how to get from “a single server” to “resilient enough for our business,” our team is happy to help you think it through in practical terms.
Start by reviewing your current SLAs, doing the downtime math, and noting where there are gaps between what’s guaranteed and what your business can tolerate. From there, you can decide if you simply need a better‑matched hosting plan, a more robust VPS or dedicated architecture, or a multi‑site strategy with DNS‑level failover. Whatever path you choose, understanding what 99.9% uptime really means will help you build a calmer, more predictable hosting environment—without relying on marketing numbers alone.
