A 99.9% uptime guarantee sounds like a near-perfect number. Three nines. Basically always on.
In hours, a 99.9% uptime guarantee allows for 8 hours and 45 minutes of downtime per year. That is more than a full working day, every single year, and the hosting provider is still meeting its guarantee.
Move one decimal point and the picture changes dramatically. 99.99% allows 52 minutes per year. 99% allows 3 days, 15 hours. The difference between these numbers looks small on a marketing page and is enormous in practice, and almost no one converts the percentage into a real number before choosing a host based on it.
This guide converts every common uptime guarantee into actual downtime, explains how providers measure it (and the gaps in that measurement), what the SLA credit actually compensates you for when downtime exceeds the guarantee, and what matters more than the percentage itself when evaluating real reliability.
A 99.9% Uptime Guarantee in Context: The Full Conversion Table
Here is the conversion every hosting comparison should include and almost none do. Each row shows the maximum downtime allowed at that uptime percentage, calculated against a full year (8,760 hours).
| Uptime Percentage | Downtime Per Year | Downtime Per Month | Downtime Per Week | Downtime Per Day |
|---|---|---|---|---|
| 99% | 3 days, 15 hours, 36 minutes | 7 hours, 18 minutes | 1 hour, 41 minutes | 14 minutes, 24 seconds |
| 99.5% | 1 day, 19 hours, 48 minutes | 3 hours, 39 minutes | 50 minutes, 36 seconds | 7 minutes, 12 seconds |
| 99.9% | 8 hours, 45 minutes, 36 seconds | 43 minutes, 49 seconds | 10 minutes, 4 seconds | 1 minute, 26 seconds |
| 99.95% | 4 hours, 22 minutes, 48 seconds | 21 minutes, 54 seconds | 5 minutes, 2 seconds | 43 seconds |
| 99.99% | 52 minutes, 34 seconds | 4 minutes, 22 seconds | 1 minute, 1 second | 8.6 seconds |
| 99.999% | 5 minutes, 15 seconds | 26 seconds | 6 seconds | 0.9 seconds |
A few things become obvious looking at this table together.
The jump from 99% to 99.9% looks like “adding a nine,” a small change in notation. In reality it is the difference between 3.5 days of allowed downtime per year and under 9 hours, a reduction of roughly 90%.
The jump from 99.9% to 99.99%, which looks like an even smaller notational change (adding another nine), is the difference between 8.75 hours and under an hour, another roughly 90% reduction. Each additional nine represents roughly a 10x improvement, not a marginal one, which is why each additional nine becomes progressively more expensive and difficult for a provider to deliver.
99.999% (sometimes called “five nines,” historically associated with telecom-grade reliability) allows just over five minutes of downtime per year. Almost no mainstream hosting provider offers this as a guarantee for shared or typical VPS hosting, because achieving it requires infrastructure redundancy, of the kind described in AWS’s own SLA documentation, that is only economical at a scale most hosting accounts do not reach.
Why a 99.9% Uptime Guarantee Is the Most Common Number in Hosting
99.9% has become the default SLA figure across shared hosting, managed WordPress hosting, and many VPS and cloud providers, and the reason is more about what it represents operationally than what it represents marketing-wise.
8.75 hours of downtime per year is roughly the amount of downtime that occurs from a combination of: a handful of brief outages from routine infrastructure issues (a few minutes each, several times a year), a small number of longer incidents during major issues (a server migration that takes longer than planned, a data centre network issue), and the accumulated effect of smaller blips that individually would not even be noticed but add up over a year of continuous operation.
In other words, 99.9% is roughly where most competently-run infrastructure naturally lands without extraordinary additional investment. Providers can offer it confidently because it reflects realistic operational outcomes, not because it represents a stretch target they are working hard to hit.
This is also why 99.9% is offered so broadly: it is achievable enough that providers can offer it as a standard guarantee across their entire customer base without it becoming a significant cost or operational burden, while still sounding impressive enough (three nines) to function as a marketing figure.
Higher figures (99.95%, 99.99%) typically appear on premium tiers, enterprise plans, or services with architectural redundancy built in specifically (multiple availability zones, automatic failover), because reaching them requires infrastructure investment beyond what “competent operations” alone delivers.
How Uptime Is Actually Measured
The 99.9% figure is meaningless without understanding what it is measured against, and this is where the gap between the guarantee and your actual experience often opens up.
Most providers measure uptime at the server or infrastructure level, not at the application level. A common measurement approach checks whether the server itself is responding to basic network requests (a ping, or a simple HTTP request to a default page) at regular intervals. If the server responds, that interval counts as “up,” even if your specific website is returning errors, your database connection is failing, or your application is timing out, because none of those conditions necessarily prevent the underlying server from responding to the basic check the provider’s monitoring performs.
This means a provider’s 99.9% uptime guarantee can be technically met for a billing period during which your specific website experienced significant downtime from your visitors’ perspective, because the provider’s measurement and your website’s actual availability are not the same thing.
The measurement interval matters. If uptime is checked every five minutes, an outage that lasts four minutes and recovers before the next check may not register as downtime at all in the provider’s records, even though visitors during those four minutes experienced a down site.
Who is doing the measuring matters. Some providers use third-party monitoring services for their published uptime statistics, which is more credible than self-reported figures, because a third party has no incentive to under-report outages. Others rely fully on internal monitoring, which is not necessarily inaccurate but carries an inherent conflict of interest: the same party that sets the SLA also measures compliance with it.
What Counts as “Downtime” (and What Quietly Does Not)
The fine print of an SLA defines what counts toward the uptime calculation, and the exclusions are where a 99.9% uptime guarantee can become significantly less meaningful than it first appears.
Scheduled maintenance is almost universally excluded. If a provider needs to take a server offline for a planned update, and they notify customers in advance according to whatever notice period their terms specify (commonly 24 to 72 hours), that downtime typically does not count against the uptime guarantee at all. A provider could, in principle, schedule maintenance windows that add up to several hours per year, none of which affects their published uptime percentage, while your site is genuinely unavailable during those windows.
Force majeure exclusions typically cover events outside the provider’s control: natural disasters, widespread internet infrastructure failures, and similar events. These exclusions are standard and reasonable, but they mean a major regional outage affecting your site does not count against the guarantee even if your site was down for an extended period as a result.
DDoS attacks and security incidents are sometimes excluded, depending on the provider’s terms, on the basis that the provider’s infrastructure was not at fault even though your site was unavailable.
Issues caused by the customer (a misconfigured application, a plugin that crashes the server, exceeding resource limits) are excluded, which is reasonable, but it means the SLA only covers infrastructure-side downtime, while many real-world outages on shared and budget hosting are caused by resource contention from other accounts on the same server, a grey area that may or may not be classified as the provider’s responsibility depending on how it is framed.
The practical effect: read the SLA’s downtime definition and exclusion list, not just the headline percentage. A 99.9% uptime guarantee with broad exclusions may, in practice, cover a smaller portion of your actual availability risk than a 99.5% guarantee with narrow exclusions, even though the headline number suggests the opposite.
SLA Credits: What You Actually Get When the Guarantee Is Missed
When a provider fails to meet its uptime guarantee, the standard remedy is an SLA credit: a partial refund or account credit, not a cash payment, and almost never compensation for any actual business impact the downtime caused.
A typical SLA credit structure looks something like this:
| Actual Uptime | Credit |
|---|---|
| Below 99.9% (the guaranteed level) | 10% of monthly fee |
| Below 99% | 25% of monthly fee |
| Below 95% | 50% of monthly fee |
On a hosting plan costing $20 per month, a 10% credit is $2. If your site was down for, say, 12 hours during a month (well beyond the 99.9% allowance), and that downtime caused lost sales, lost leads, or reputational damage, the SLA credit of $2 does not come close to addressing the actual impact.
This is the most important thing to understand about any uptime guarantee: the SLA credit is not insurance against the business cost of downtime. It is a discount on your hosting bill, calibrated to the cost of the hosting, not the cost of the downtime to your business.
For a personal blog, this is a reasonable framing: hosting costs are low, the impact of downtime is low, and a proportional credit makes sense. For a business where downtime directly costs revenue (an e-commerce store during a sale, a SaaS product with paying customers, a lead-generation site running paid ads), the SLA credit structure means the actual financial exposure to downtime is borne fully by the business, not the hosting provider, regardless of what the uptime percentage promises.
Claiming the credit is also usually not automatic. Most SLAs require the customer to submit a claim within a specified window (often 30 days), often with supporting evidence (timestamps, ticket numbers from when the issue was reported). Providers do not typically proactively issue credits when they miss their own guarantee; the burden is on the customer to notice, document, and claim.
A 99.9% Uptime Guarantee vs 99.99%: Why Small Differences Matter So Much
The reason percentage differences that look small produce dramatically different downtime figures comes down to how percentages compress at the high end.
Going from 90% to 99% is a 9 percentage point difference, and reduces downtime from 36.5 days per year to 3.65 days per year, a 10x reduction.
Going from 99% to 99.9% is a 0.9 percentage point difference, less than one point, and reduces downtime from 3.65 days to 8.76 hours, also roughly a 10x reduction.
Going from 99.9% to 99.99% is a 0.09 percentage point difference, and again produces roughly a 10x reduction, from 8.76 hours to 52.6 minutes.
Each additional nine is a 10x improvement in allowed downtime, while the percentage figure itself moves by a fraction that looks almost identical to the previous step on a marketing page. “99.9% vs 99.99%” reads as a trivial difference. “8.76 hours vs 52.6 minutes” reads as a meaningful difference, because it is one.
This is precisely why converting the percentage to actual time before comparing providers, or before comparing tiers within the same provider, changes the comparison. A premium plan advertising 99.99% instead of a standard plan’s 99.9% is not offering “0.09% more uptime” in any meaningful sense; it is offering roughly ten times less potential downtime.
Real-World Uptime vs Advertised Uptime
The advertised uptime guarantee is a contractual floor, not a prediction of actual performance, and the two are often quite different in practice, in both directions.
Many providers significantly exceed their stated guarantee in practice. A provider offering a 99.9% SLA might actually achieve 99.95% or 99.97% in a typical year, because the guaranteed figure is set conservatively (partly to account for the exclusions discussed earlier, and partly because providers do not want to promise a figure they might occasionally miss). For these providers, the SLA figure understates real-world reliability.
Some providers operate close to their guaranteed floor consistently. If a provider’s actual performance regularly sits close to 99.9% with little margin, occasional months will fall below it, triggering the (minimal) credit process, while other months sit just above it. For these providers, the SLA figure is a more accurate predictor of what you should expect.
The only way to know which kind of provider you are dealing with is independent, historical data, not the SLA figure itself. Third-party uptime monitoring services like Pingdom that track many hosting providers over time, status page histories (many providers maintain a public status page, often built on tools like Statuspage, showing past incidents), and independent reviews that include uptime tracking over months are all more informative than the SLA percentage for predicting actual experience.
Website uptime directly affects search rankings and visitor trust, which is why the gap between advertised and actual uptime matters beyond the SLA credit calculation: the business impact of downtime (lost search visibility, lost conversions, damaged trust) occurs regardless of whether the provider’s SLA technically covers that specific incident.
What to Check Instead of the Percentage
Given everything above, here is what provides more signal than the headline uptime percentage when evaluating a host.
Historical uptime data from independent monitoring, covering at least six months and ideally a full year, shows actual performance rather than a contractual promise. A provider with a 99.9% SLA that has independently verified 99.97% actual uptime over the past year is a stronger signal than the SLA number alone.
The provider’s status page history. How frequently do incidents occur, how long do they typically last, and how transparent is the provider about communicating during an incident. A status page with frequent, well-documented, quickly-resolved incidents can sometimes indicate a more reliable provider than one with an empty status page, if the empty page reflects under-reporting rather than genuinely fewer incidents.
The architecture behind the guarantee. How load balancing is implemented on shared hosting affects whether a single server issue takes down your specific site or is absorbed by redundancy. A 99.9% guarantee on infrastructure with genuine redundancy behind it is a different risk profile than the same percentage on a single-server setup with no failover, even if both providers publish the identical SLA number.
What happens during an incident, not just how often incidents occur. Support responsiveness during an active outage, communication quality, and how quickly issues are typically resolved all affect the real-world impact of any given amount of downtime. Two providers with identical actual uptime can produce very different experiences if one resolves issues in minutes with proactive communication and the other takes hours with no status updates.
How to Monitor Your Own Uptime Independently
Rather than relying fully on a provider’s published figures, independent monitoring gives you your own record of your site’s actual availability, which is useful both for holding a provider accountable and for understanding your real-world reliability regardless of what any SLA covers.
Set up an external uptime monitor that checks your site from outside your hosting infrastructure, at a short interval (one to five minutes), with alerting. A free tier on a service like UptimeRobot covers this for most small sites. Run this continuously, not just when you suspect a problem, so that you have a historical record to refer to.
Over time, this gives you your own uptime percentage, calculated from your visitors’ actual experience (or as close to it as an external check can approximate), which you can compare against the provider’s SLA. If your independent monitoring consistently shows uptime below what the provider claims, that is useful evidence both for any SLA credit claim and for deciding whether to continue with that provider.
This monitoring is also the foundation for diagnosing problems when they occur. If your monitor alerts you to downtime, the next step is determining the cause, and a systematic approach to diagnosing server issues (for VPS and dedicated infrastructure where you have diagnostic access) helps distinguish a brief blip from a pattern that indicates a deeper infrastructure problem worth addressing, whether that means a configuration change or a provider change.
When 99.9% Is Genuinely Fine, and When It Is Not
Not every website needs to optimise for the highest available uptime percentage, and understanding where your site falls matters more than chasing an extra nine.
99.9% is genuinely fine for: personal websites and blogs where 8.75 hours of cumulative downtime per year, likely spread across many brief incidents rather than one long one, has negligible practical impact; informational sites where a visitor encountering a brief outage simply tries again later with no lasting consequence; early-stage projects where the cost difference between hosting tiers is more significant than the reliability difference at this stage.
99.9% may not be sufficient for: e-commerce stores, where even brief downtime during peak shopping periods directly costs sales, and where the timing of downtime (not just the total amount) matters enormously; SaaS products with paying customers who have their own expectations and possibly their own SLAs with you, creating a dependency chain where your hosting’s downtime becomes your downtime to your customers; any business where a competitor being available during your downtime represents a lost customer, not just a delayed one; sites with significant paid advertising spend, where downtime during an active campaign wastes ad spend directly.
For businesses in the second category, the conversation should move beyond the percentage fully, toward architecture: understanding when a business has actually outgrown shared or standard VPS infrastructure and needs redundancy designed in rather than a higher number on an SLA. A higher SLA percentage on the same underlying architecture is often a smaller improvement than redesigning the architecture itself for redundancy, regardless of what percentage results.
Backup and recovery processes are also part of this picture: an uptime guarantee addresses how often the server is available, not how quickly a serious incident (data loss, a failed migration, a security compromise) can be recovered from. A site with excellent uptime but no tested backup process has a different, and in some ways larger, risk than a site with slightly lower uptime and a verified, tested recovery process.
Frequently Asked Questions
Is a 99.9% Uptime Guarantee Good for a Website?
For most personal websites, blogs, and small business informational sites, a 99.9% uptime guarantee is adequate. It permits 8.75 hours of downtime per year, which for most such sites translates to brief, infrequent interruptions with minimal practical impact. For e-commerce stores, SaaS products, or any business where downtime directly and immediately costs revenue, 99.9% represents a meaningful amount of potential lost availability, and the SLA credit for missing it (typically around 10% of the monthly hosting fee) does not compensate for the business impact of that downtime.
How Many Hours of Downtime Does a 99.9% Uptime Guarantee Allow Per Month?
A 99.9% uptime guarantee allows approximately 43 minutes and 48 seconds of downtime per month, calculated as one-twelfth of the annual allowance. Over a full year, this totals approximately 8 hours and 45 minutes. The monthly figure is often more relevant than the annual figure because most SLA credit calculations are based on monthly uptime percentages, not annual ones.
What is better, 99.9% or 99.99% uptime?
99.99% is significantly better, representing roughly ten times less allowed downtime than 99.9%. A 99.9% uptime guarantee allows 8.75 hours of downtime per year, while 99.99% allows approximately 52.6 minutes. The percentage difference (0.09 percentage points) looks small, but the practical difference is substantial. Whether the improvement justifies any additional cost depends on how costly downtime is for your specific site or business; for a site where even brief downtime has real financial impact, 99.99% can be worth a meaningful price premium.
Do hosting providers actually pay for downtime if they miss their uptime guarantee?
Hosting providers typically issue an SLA credit, which is an account credit or partial refund applied to your hosting bill, not a cash payment. The credit amount is usually a percentage of your monthly hosting fee (commonly around 10% for missing a 99.9% guarantee), and is unrelated to any actual financial loss the downtime may have caused your business. Most providers also require you to proactively submit a claim, often within a specific time window and with supporting documentation, rather than automatically applying credits when they miss their own guarantee.
Does scheduled maintenance count against an uptime guarantee?
Almost universally, no. Scheduled maintenance that the provider announces in advance (the required notice period varies but is often 24 to 72 hours) is typically excluded from uptime calculations fully. This means a provider can be offline for maintenance for a meaningful amount of time per year while still reporting 100% uptime against their SLA, because scheduled maintenance windows simply do not count toward the calculation in either direction.
How is uptime percentage actually calculated?
Uptime percentage is calculated as the proportion of time a service was available out of the total time in the measurement period, typically a calendar month for SLA purposes. The formula, the same one used by Google’s own SLA calculations, is: (total minutes in the period minus downtime minutes) divided by total minutes in the period, multiplied by 100. The accuracy of this calculation depends fully on how “downtime” is detected and defined, which is determined by the provider’s monitoring method, monitoring interval, and the exclusions specified in their SLA terms, all of which can cause the calculated percentage to differ from what your actual visitors experienced.
Should I choose a host based primarily on its uptime guarantee percentage?
The uptime guarantee percentage alone is a weak signal because it represents a contractual floor with significant exclusions, not a measurement of real-world performance, and the remedy for missing it (a small account credit) does not reflect the actual cost of downtime to most businesses. Independent, historical uptime data covering several months, the provider’s status page history and incident transparency, and the underlying infrastructure architecture (whether redundancy is built in or a single point of failure exists) all provide more useful information than the headline percentage when comparing hosting providers.
