Is Your Host Really 99.9% Uptime? How to Verify

Direct answer: Probably not, and probably not intentionally. 99.9% uptime means your host is allowed up to 8 hours and 46 minutes of downtime per year per the Wikipedia high-availability standard, or roughly 43 minutes per 30-day month. Most months your host hits the number. The catch is the bad months: when an outage happens, the host's status page often lags the incident by minutes to hours (AWS's own post-mortem on the December 7, 2021 us-east-1 outage admits a 52-minute gap), and every major SLA (AWS, Vercel, Cloudflare, Kinsta, WPEngine) requires you to file a credit claim with your own evidence within a tight window. The fix is independent monitoring that runs from outside your host's network, captures timestamps and response codes during the incident, and gives you the evidence the SLA requires. Velprove's free plan covers HTTP monitoring across 5 regions plus a browser login monitor at no cost.

What 99.9% uptime actually means

The math is settled and primary-sourced. Per the Wikipedia high-availability table (en.wikipedia.org/wiki/High_availability, verified 2026-05-06), 99% uptime allows 3.65 days of downtime per year. 99.9% allows 8.77 hours per year. 99.95% allows 4.38 hours per year. 99.99% allows 52.60 minutes per year. 99.999% allows 5.26 minutes per year. Those are the standard annual figures every provider, every SLA, and every monitoring tool draws from.

The per-month figures are arithmetic, not quoted. An average month is 30.44 days, or 730.5 hours. 99.9% of 730.5 hours leaves about 43.83 minutes of allowed downtime per month. 99.95% leaves about 21.92 minutes. 99.99% leaves about 4.38 minutes. 99.999% leaves about 26.3 seconds.

Cross-check: Hostinger's own marketing page derives the same per-month number, calling out approximately 43.8 minutes of downtime per month at 99.9%. When the vendor's math agrees with the standard, the math is not in dispute. The argument is whether your host actually hits the number, and whether you have the evidence to prove it when they do not.

One nuance worth keeping in mind. Providers internally target tighter SLOs than they publish externally. A vendor may run to 99.99% internally while publishing a 99.9% SLA, treating the gap as their safety margin. That is why most months the published number is easy to hit. Your job as a customer is not to chase every short outage. It is to monitor consistently so when a bad month happens, the evidence is already on your side. If you are new to uptime monitoring, start here.

What major hosts actually promise

Verbatim SLA language from the seven hosts whose primary-source SLA pages we verified directly on 2026-05-06. Every percentage and every credit mechanic in the table below comes from the host's own legal page, linked in the source column.

Cloudflare Business publishes "100% Uptime. The Service will serve Customer Content 100% of the time without qualification" for Business-tier customers (cloudflare.com/business-sla). AWS EC2 publishes 99.99% at the region level and 99.5% at the instance level (aws.amazon.com/compute/sla). Vercel publishes 99.99%, but only on the Enterprise plan; Hobby and Pro have no SLA at all (vercel.com/legal/sla). Kinsta defaults to 99.9% with a tiered minute-by-minute credit schedule. WPEngine publishes 99.95% with a 5%-per-hour overage credit. Hostinger publishes 99.9% on shared hosting with a 5% credit. OVHcloud publishes 99.99% / 99.95% / 99.90% across its Public Cloud tiers.

Two patterns the table makes obvious. First, Vercel and Netlify Hobby/Pro plans have no SLA mechanism at all. Most users on those tiers have no credit recourse when an incident happens; they have community pressure and that is it. Second, every SLA excludes the same broad categories: scheduled maintenance, force majeure, customer-caused issues, third-party routing, and beta features. The exclusions are standard, not bad faith. The leverage from independent monitoring is not to dispute exclusions. It is to prove the outage happened, when it happened, and from where it was visible, so the vendor cannot classify it under an exclusion without evidence.

Why your host's status page doesn't reflect reality

On December 7, 2021, AWS us-east-1 went down. AWS's own post-mortem (aws.amazon.com/message/12721, verified 2026-05-06) states the outage began at 7:30 AM PST. The same post-mortem states "by 8:22 AM PST, we were successfully updating the Service Health Dashboard." That is a 52-minute gap between when the outage began and when AWS's own status page reflected it. The cause, in AWS's words: "The networking congestion impaired our Service Health Dashboard tooling from appropriately failing over to our standby region."

AWS is the most-resourced cloud provider on Earth. Their dashboard still lagged a major incident by 52 minutes. Independent monitoring sees the outage at minute one.

The structural reason is well-documented. The Register's February 2022 reporting on cloud status page accuracy (theregister.com, verified 2026-05-06) quotes Tim Perry of HTTP Toolkit: "It is very common to see status pages fail to match reality." Nick Humrich, a former AWS engineer, told The Register that "posting a non-green status to the status page was actually a manager decision, in no way real time." Tim Perry adds: "I strongly suspect this is because the published status is linked to contractual SLAs, financial penalties in those contracts."

The mechanism is straightforward. The vendor controls the status page. The vendor has financial exposure for marking the page non-green. The customer cannot rely on a self-reported status as evidence of an outage they need to file a credit claim against. Independent monitoring has no financial incentive to lie about whether your site responded. Your host does.

How to verify with independent monitoring

The Google SRE Book is the canonical reference here. Google's own engineers describe black-box monitoring (sre.google/sre-book/monitoring-distributed-systems, verified 2026-05-06) as "testing externally visible behavior as a user would see it" and add that "black-box monitoring is symptom-oriented and represents active, not predicted, problems: 'The system isn't working correctly, right now.'" The same chapter notes that Google itself combines "heavy use of white-box monitoring with modest but critical uses of black-box monitoring." The split maps cleanly onto the customer-vendor relationship: the vendor runs white-box monitoring (their internal metrics). You run black-box monitoring (probing as a user from outside). Both are needed. You cannot trust just one.

What good independent monitoring looks like in practice: HTTP monitors on your homepage and key pages, multi-region probes so a regional failure does not look like a global failure or vice versa, and a browser login monitor for auth-protected pages. Browser login monitoring catches the partial outage HTTP-only monitoring misses when your homepage is fine but logged-in customers cannot reach checkout. It is also worth knowing the common mistakes that cause monitoring to miss outages before you set thresholds.

Velprove's free plan covers exactly this surface. 10 HTTP monitors at a 5-minute minimum interval. 1 browser login monitor at a 15-minute interval. 5 global monitoring regions on every plan including Free. Email alerts. SSL certificate monitoring. 30-day incident history. 1 status page at velprove.com/status/your-page. No credit card required. The browser login monitor is the piece most monitoring tools either charge for or omit from the free tier entirely.

How to file an SLA credit claim

Every primary-source SLA in the table above requires the customer to file a claim. None of them auto-detect a missed SLA and credit your account. Your evidence is what gets the credit issued.

The deadlines are short and they vary. Cloudflare Business requires notification within 5 business days of the incident, the shortest window in the table. AWS gives you until the end of the second billing cycle after the incident. Vercel, WPEngine, Kinsta, and Hostinger all set a 30-day window. OVHcloud gives 60 calendar days. If you do not have monitoring already running before the outage, by the time you notice the analytics decline a week later, the Cloudflare window is already closed.

The evidence requirements are explicit. Vercel's SLA demands "log files showing Unscheduled Downtime and the date and time it occurred." AWS demands "request logs documenting the outage." Cloudflare requires "sufficient evidence to support the Claim." The vendor's own status page does not count. The customer is asked to bring the proof.

Honest framing on the credit value. On a $4 a month Hostinger shared plan, the 5% credit for a missed-SLA month is 20 cents. On a $40 a month Kinsta plan, a one-hour outage credit is $4. The dollar amount is rarely the leverage. The leverage is the documented record. A documented record gives you evidence in renewal negotiations or when escalating to a senior account manager. A pattern of repeated misses is grounds for migrating without an early-termination penalty under most contracts. For agencies, a documented record is what you show your client when you recommend a migration. The framing is not adversarial. You are bringing the data and asking the vendor to honor their own published SLA.

When to escalate, renegotiate, or migrate

A simple decision tree, calibrated for the realistic case where you have a few months of independent monitoring data in hand.

• One bad month, otherwise reliable. File the credit claim within the deadline, take the credit, move on. Most providers in most quarters hit their published number; one bad month is not a structural problem.
• Repeated misses (3 or more months out of 6). Bring the documented record to a senior account manager. Ask politely for a service review. The data is what gets a serious response; without it the conversation goes nowhere.
• Pattern of misses plus slow vendor response on the credit claims. Migrate. The documented record is grounds for terminating without an early-termination penalty under most contracts, and it is what you bring to the next vendor when negotiating their SLA terms.

Before you migrate, rule out the possibility the problem is on your side. If your site keeps going down, here is how to diagnose whether it is the host or your application. An external monitor will name the cause within minutes either way.

Frequently Asked Questions

What does 99.9% uptime actually mean in downtime?

99.9% uptime allows up to 8 hours and 46 minutes of downtime per year, or roughly 43 minutes and 50 seconds per 30-day month, per the Wikipedia high-availability standard. 99.99% allows 52.6 minutes per year, or about 4.38 minutes per month. 99.999% allows 5.26 minutes per year. Most hosts publish 99.9% and most months easily hit it. The math matters when a bad month happens.

How do I check my website's uptime independently?

Run an external monitor that probes your site from outside your host's network on a fixed schedule. Velprove's free plan runs HTTP monitors every 5 minutes from 5 global regions and includes a browser login monitor for auth-protected pages at no cost. The point of independent is that the monitor has no financial relationship to your host, so its data is admissible evidence when you file an SLA credit claim.

How do I prove my hosting provider is down?

Capture timestamped probe results from a third-party monitor that ran from multiple regions during the incident. The data needs to show response codes or timeouts, the time the failure started, the time it recovered, and the regions affected. Every major SLA (Vercel, AWS, Cloudflare) explicitly requires customer-side log files as evidence. Your host's status page does not count as proof, because your host controls it. Velprove's free plan runs HTTP probes from 5 global regions and stores 30 days of incident history, which is the evidence shape every major SLA requires.

Can I get a refund for hosting downtime?

Usually a service credit, not a cash refund. Every major host (AWS, Vercel, Cloudflare, Kinsta, WPEngine, Hostinger, OVHcloud) publishes a credit schedule that pays out a percentage of your monthly bill if the SLA is missed. You file a claim within the deadline (5 business days for Cloudflare Business, 30 days for most others, 60 for OVHcloud) with your evidence. Credit caps are typically 100% of one month's fees. The dollar value is usually small. The documented record is the leverage.

Why does my host's status page say green when my site is down?

Status pages are vendor-controlled and often lag the actual incident by minutes to hours. AWS's own post-mortem on the December 7, 2021 us-east-1 outage admits a 52-minute gap between when the outage began (7:30 AM PST) and when their Service Health Dashboard reflected it (8:22 AM PST). Former AWS engineers have stated publicly that posting a non-green status was a manager decision, not real-time automation. The structural reason is that status updates link to SLA financial exposure, which creates a disincentive to mark non-green.

What's the cheapest way to start verifying my host's uptime?

Velprove's free plan covers HTTP monitoring across 5 global regions, a browser login monitor for auth-protected pages, a public status page, and email alerts at no cost. No credit card required. The browser login monitor is the differentiator: most major monitoring tools charge for it or omit it from their free tier entirely. Sign up, point a monitor at your site, and you will have the timestamped evidence trail running before the next bad month happens.

Your host's 99.9% claim is probably accurate most months. Independent monitoring is what tells you which months it is not, and gives you the timestamped evidence every major SLA already requires you to bring to the credit claim. Start a free Velprove account. The free plan includes a browser login monitor most monitoring tools charge for, plus 10 HTTP monitors across 5 global regions and a public status page. No credit card required.