Your host's uptime guarantee and your uptime monitor measure two different things, which is why they disagree. The guarantee covers the provider's own infrastructure, measured at their network edge, with maintenance windows and anything caused by your code carved out. Your monitor measures what a visitor gets from the public internet, including your application, your DNS, your certificate and your CDN. A host can be truthfully at 100% in a month your customers could not check out.
This comes up almost every time a team buys monitoring for the first time. The site was down for twenty minutes, the monitor has the timestamps, and the host's status page shows an unbroken green line. Nobody is lying. The two numbers were never measuring the same system.
What a hosting uptime guarantee actually covers
A hosting uptime guarantee is a contractual promise about the availability of the provider's service, which in practice means their power, network, hypervisor and storage. It is measured from inside their network, at the point where their responsibility ends and yours begins. If your server is powered on and reachable at that boundary, the provider has delivered what they sold, even if your application is returning a 500 to every request behind it.
That boundary is the whole story. On shared hosting it sits at the web server. On a VPS it sits at the virtual machine. On a managed platform it may sit further in. In every case, the guarantee stops well short of the thing your customer is trying to do.
| Failure | Counts against the host's SLA? | Your monitor sees it? |
|---|---|---|
| Their data center loses power | Yes | Yes |
| Their network drops routes | Yes | Yes |
| Your app throws a 500 on every request | No | Yes |
| A deploy ships a broken build | No | Yes |
| Your TLS certificate expires | No | Yes |
| A DNS change resolves to nothing | No | Yes |
| Your database hits max connections | No | Yes |
| A plugin or dependency breaks checkout | No | Yes |
| Your CDN serves a stale error page | No | Yes |
| Scheduled maintenance announced in advance | Usually excluded | Yes |
| A DDoS attack aimed at you | Usually excluded | Yes |
Count the rows. Two of eleven are the host's problem. That ratio is roughly what most teams find once they start logging their own incidents, and it is the reason a hosting guarantee is not a substitute for monitoring. It was never designed to be one.
Does my web host monitor my website?
No, in almost every case. Your host monitors its own infrastructure so it can meet the guarantee it sold you. It watches whether the machine is up, not whether your checkout works. Some managed hosts add a basic HTTP check as a courtesy feature, usually at a five-minute interval and usually alerting only by email. That is a different product from external monitoring, and it shares the same blind spot as everything else run from inside the provider's network: if their network is the thing having a bad day, the check that is supposed to tell you about it is having the same bad day.
External monitoring exists precisely to be somewhere else. A check that runs from outside sees the path your customer takes, including the DNS lookup, the TLS handshake, the CDN, and the response body. That is why the useful checks assert on content rather than just status: a page can return 200 and still say "Service temporarily unavailable" in the body.
Why the two numbers never match
Beyond scope, three mechanical differences pull the figures apart.
Measurement point. The host measures at its edge. You measure from the public internet. Everything between those two points, which is most of what can break, is invisible to one of you.
Sampling interval. Availability is not observed continuously, it is sampled. A monitor checking every five minutes can miss a four-minute outage entirely, and can also record a single failed sample as five minutes of downtime. Providers usually calculate from their own internal telemetry at a much finer resolution, which produces a smoother and more forgiving number. If you want your figure to hold up in a conversation, the interval is the variable that matters most, and it is the one that drives what uptime monitoring costs more than monitor count does.
Rounding and exclusions. Most SLAs round to whole minutes, ignore outages under a threshold such as five minutes, and exclude announced maintenance. Stack those three and a real hour of customer-visible trouble can legitimately reduce to zero recorded downtime.
What is a good uptime guarantee?
For general web hosting, 99.9% is the common floor and anything below 99.5% is a warning sign. 99.99% is normal for enterprise infrastructure and rare on shared hosting. The number matters less than the exclusions, though, because a 99.99% promise with a long exclusions list is worth less than a 99.9% promise with a short one. Read what is carved out before you read the percentage.
Here is what each level allows in an average month of 30.44 days, which works out to 43,833 minutes.
| Guarantee | Allowed downtime per month | Typical setting |
|---|---|---|
| 99.0% | 7 h 18 m | Budget shared hosting |
| 99.5% | 3 h 39 m | Entry VPS |
| 99.9% | 43 m 50 s | Standard hosting and most SaaS |
| 99.95% | 21 m 54 s | Managed platforms |
| 99.99% | 4 m 23 s | Enterprise infrastructure |
Two things follow from that table. A 99.9% guarantee permits nearly three quarters of an hour of downtime every month without breaching anything, which is more than most ecommerce teams assume. And at 99.99%, the entire monthly allowance is four minutes and twenty-three seconds, which a five-minute check interval cannot even resolve. We walk through the arithmetic in how to calculate uptime percentage.
The credit is smaller than you think
When a host does breach its guarantee, the remedy is almost always a service credit against a future invoice rather than a refund or any compensation for lost business. Four features of the claim process are worth knowing before you rely on it.
You usually have to file the claim yourself, within a window that is often 30 days. Credits are typically capped at a share of one month's fee. The credit is calculated on what you pay the host, not on what the outage cost you, so a $30 hosting bill produces a credit measured in single dollars regardless of the revenue that went with it. And the provider's own measurement is the one that decides whether a breach happened at all, which is exactly why independent evidence is worth having. Since the credit is a percentage of the invoice, it is also worth knowing what your infrastructure actually costs you each month before you decide how hard to chase it.
The practical conclusion is that hosting credits are not a risk transfer. They are a token. If downtime genuinely costs you money, the money is protected by detecting and fixing outages quickly, not by claiming afterwards. Our guide to SLA service credits covers the mechanics in detail, including the version you may owe your own customers.
What to do about it
None of this makes hosting guarantees worthless. It makes them one input among several. Four things close the gap.
Run your own external check. Somewhere outside your provider's network, on an interval fine enough to resolve the outages you care about. If your own commitment is 99.9%, checking every five minutes leaves a blind spot bigger than a tenth of your monthly allowance before anyone even reacts.
Assert on content, not just status codes. The failures your host will not cover are mostly application failures, and application failures are very good at returning 200. Check for a keyword, a JSON field, or a response-time budget.
Confirm before you page. A single probe failing from a single location is a network hiccup as often as it is an outage. Requiring agreement from more than one region before alerting is what keeps a monitor credible enough that people still answer it at 3am.
Keep the record. Timestamped check history from a third party is the only evidence you will have in a disagreement with a provider, and it is the same evidence you need if you owe an uptime commitment to your own customers. That is the difference between an opinion and a report, and it is what SLA monitoring is for.
Should I still care what my host guarantees?
Yes, as a signal about the provider rather than as protection. A host willing to put 99.99% in writing with a short exclusions list is telling you something real about how it runs its infrastructure. A host that publishes no guarantee at all is telling you something too. Just do not confuse either message with knowing whether your site is up, because that is a question only a check from outside can answer. If you are working out what that check should cost, the uptime monitoring pricing comparison lays out fifteen tools in US dollars, and website monitoring explains how our own checks are put together.