“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?
Choosing hosting by its advertised uptime percentage alone can leave important gaps unnoticed: the Service Level Agreement (SLA) may not cover the outages that matter to your application. 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 explain how to choose uptime targets for hosting, VPS, dedicated server, and colocation setups.
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 at the application level is about the end result: can users actually complete what they came to do? An SLA may instead define availability at the infrastructure level. 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 % | Downtime at target per month | Downtime at target 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 48 seconds | ~8 hours 46 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 use a 365‑day year and an average month of 365/12 days, with no exclusions. For a 30‑day month, 99.9% corresponds to 43 minutes 12 seconds of downtime. Actual SLA allowances depend on the measurement period and exclusions; the yearly column is a comparison, not a separate annual guarantee.
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:
- Allowing a single 30–40 minute counted outage within a 99.9% monthly target, provided other counted outages do not exhaust the remaining budget
- Keeping all counted downtime combined below roughly 4.4 minutes in an average month for 99.99%, potentially using automatic failover to reduce interruption
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
Infrastructure planning should consider uptime at different layers: even a reliable network cannot keep a service available if its storage tier fails without redundancy.
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
In this simplified formula, “Unplanned downtime minutes” means only downtime counted under the SLA. Check whether excluded periods are also removed from the total measurement time. Clauses may exclude specific types of downtime, such as:
- Scheduled maintenance
- Emergency security patches
- Force majeure (natural disasters, large‑scale internet issues)
- Customer‑caused incidents (such as misconfiguration or attack traffic originating from a compromised customer system)
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?
Some SLAs count only a complete loss of connectivity or define “unavailability” using the provider’s monitoring systems. Check the monitoring locations and thresholds: an outage affecting a particular user base or region may not meet that definition.
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.
Example 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% up to but not including 99.9%: credit equal to 10% of the monthly fee
- 95.0% up to but not including 99.0%: 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: Check whether credits are capped, and which service fee and measurement period determine that limit
- 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 receiving a $25 service credit, not necessarily a cash refund. 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 a framework for making that decision.
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
These bands are illustrative starting points, not industry standards. Choose a target based on your downtime costs, contractual obligations, and maximum tolerable outage duration:
- “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: your hosting provider’s SLA is a contractual target for covered infrastructure, not a prediction of your application’s availability. Deployments, application bugs, and third‑party dependencies can reduce end‑to‑end availability; redundancy can help it exceed an individual component’s SLA target.
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 to compare with SLA metrics, accounting for differences in scope, measurement windows, and exclusions
Use multiple locations if possible; this helps you distinguish between local ISP issues and real server‑side downtime.
Internal Server Monitoring
External uptime checks show whether the tested endpoints respond as expected; internal metrics help you investigate why a check failed. 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 may see patterns: specific times of day, recurring error types, or resource exhaustion. These can guide application fixes or capacity changes, such as upgrading from shared hosting to a VPS. Repeated infrastructure outages may instead justify moving 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
Here is a summary of pitfalls to check 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. Check how the SLA treats cybersecurity threats and DDoS attacks. If your site is taken offline in a mitigation effort, will that downtime be excluded from SLA calculations?
Gotcha 4: Provider Measurements May Differ from Yours
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 hosting SLAs typically define service-level commitments for specified infrastructure, along with exclusions and remedies. They do not guarantee that your overall business will meet an availability target. To support end‑to‑end availability, consider:
- Redundant hosting (VPS or dedicated) across multiple availability zones or data centers
- Robust DNS strategies like Anycast and failover
- Tested recovery workflows and runbooks
- 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.
When discussing hosting, VPS, dedicated server, or colocation options with DCHost, ask how the proposed infrastructure supports your uptime target and which layers the SLA covers. The SLA is one layer; sensible monitoring, tested backups, and—when appropriate—redundant setups should address the node, rack, or data center failures your business needs to tolerate. If you’re not sure what level of uptime you really need, prepare your current architecture, critical dependencies, and maximum tolerable downtime for a practical discussion with the team.
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.
