How to Read a Hosting Uptime Guarantee

On 20 September 2026 I read Bluehost’s shared hosting page and it advertised a “99.99% Uptime SLA” next to the plans. IONOS advertises 99.99% uptime too. Those are their claims, on their own pages, and I have no way to confirm or contradict either of them, because I have never been a customer of either company and I did not open the service agreements behind those numbers.

That sentence is the honest position almost every hosting article is in, and almost none of them admit it. So rather than pretend to audit somebody else’s uptime, this post does three things I can actually do: the arithmetic, which nobody can fake; the list of questions a guarantee has to survive; and the rule I have set for myself about when a number gets published on this site, which is a rule I am currently failing to meet.

The nines, converted into hours you can picture

This is the only part of the subject that is not marketing. A percentage is a promise about how much downtime is allowed, so turn it back into time.

Two things fall out of that table. The gap between 99.9% and 99.99% is not a rounding difference, it is the difference between most of a working day and one coffee break, per year. And a 99.99% promise leaves roughly four minutes a month of room, which is a very confident thing for anyone to print on a shared hosting page aimed at $3 customers.

What I can and cannot say about specific guarantees

What I checked on 20 September 2026 was pricing and plan pages, not legal agreements. So the truthful summary is short:

• Bluehost’s shared hosting page advertises a 99.99% Uptime SLA and a 30-day money-back period. Bluehost’s claim, not a verified fact, and I am not a customer.
• IONOS advertises 99.99% uptime. Same status: their claim. I look after a domain at IONOS, which tells me nothing whatsoever about their hosting uptime.
• Netlify lists a 99.99% SLA on its Enterprise plan only. That is worth noticing: on that pricing page the guarantee is a feature of the top tier, not a property of the platform.

I did not read the underlying service agreements for any of them, so I am not going to summarise exclusion clauses, measurement windows or claim deadlines and imply I have seen them. If you want to know what your host’s guarantee actually means, the document is on their site and it is the one thing in this whole topic worth twenty minutes of your own reading.

The four questions a guarantee has to survive

When I do open one of these documents, these are the things I look for, in this order. They are the difference between a commitment and a slogan.

1. What counts as down? A server answering on port 443 is not the same as your site working. If the definition is “server reachable”, a WordPress install throwing a database error all afternoon can be inside the guarantee.
2. Who measures it, and at what resolution? If the answer is the provider’s own monitoring, the provider is both player and referee. That is not necessarily dishonest, but it is worth knowing before you plan around it.
3. What is excluded? Scheduled maintenance is the usual one, and the interesting question is whether there is a cap on how much of it there can be.
4. What do you get, and do you have to ask? If compensation is a service credit you must claim within a deadline, then in practice most breaches are never compensated, because nobody files. A guarantee you have to chase is a guarantee priced on the assumption you will not.

None of those four is answered by the percentage on the pricing page, which is why the percentage is close to worthless as a way of choosing between hosts. It belongs in the same bucket as the other things I check before committing, listed in the checklist I run before putting a site on a host.

Why there is no uptime figure for my own sites in this post

Because I do not have one, and I would rather say so than round up a feeling into a percentage.

The rule I have written down for this site is simple: no uptime number gets published until I have at least 30 consecutive days of external monitoring on the site in question, and the post says which monitor, from where, and at what interval. A five-minute check for 30 days is 8,640 observations, which is enough to say something. Five requests on one afternoon, which is all I currently have, is enough to say nothing at all.

There is a subtlety in that rule worth spelling out, because it cuts against my own case. A monitor checking every five minutes cannot see an outage shorter than five minutes, and it attributes each failed check to a full interval. Against a 99.9% monthly allowance of 43 minutes, a five-minute resolution is more than a tenth of the entire budget. So even with a month of data, I will be able to say “my monitor recorded X” and not “my host delivered X”. Those are different sentences and I intend to keep writing the first one.

“Up” is a very low bar, and I have the evidence on my own site

Here is where the uptime frame breaks down, and my own sites are the example.

On 20 September 2026 I measured five requests to each of my sites from home fibre in Valencia, Spain, with curl. Every single request succeeded. Any uptime monitor watching would have recorded a flawless afternoon. But on vireltify.com, one of my two WordPress blogs on a shared plan, time to first byte ranged from 0.534 s to 1.500 s across those five consecutive requests, on a site with no traffic on it. The slowest response was nearly three times the fastest. A monitor would have called all five “up” and told me nothing.

The reason is not mysterious and it is my own fault: neither blog returned any page-cache header that day, so every request was rebuilt by PHP 8.3.33 rather than served from a cache. That is the story in I thought my blog was cached, it was not, and it is the thing I should have fixed before I ever worried about somebody else’s SLA.

Worse, my own site has been serving HTTP 200 on pages that were broken in ways no monitor detects. Twenty-six posts on this blog carried a call-to-action button pointing at an unresolved placeholder URL that returned a 404. Uptime: perfect. Page working: no. Every one of those pages would have passed any availability check ever written, which is my favourite argument against treating uptime as a proxy for quality.

The starkest example I have is not a timing at all. For about two weeks in September 2026 the domain of my VPS app was suspended at the registrar, because I had not clicked a contact-verification email sent the month before. The server stayed up the entire time. A monitor pointed at the machine would have recorded a flawless month while nobody could reach the site by its name. What that taught me about registrars is in the three registrars I use.

What I check instead, since the guarantee tells me so little

These take about ten minutes per site and every one of them is something you can verify yourself, with no account and no trial:

• Certificate validity and who issues it. On my own sites the shared plan was serving Let’s Encrypt certificates, one valid to 6 December 2026 and another to 26 October 2026, all issued and renewed without me doing anything. A host that makes you think about certificates at all is telling you something.
• Whether anything is cached. One curl -sI tells you whether a cache header comes back. Mine did not, which is how this whole investigation started.
• When the domain expires, and whether the registrar can reach you. The expiry date, the auto-renew switch, and the address the registrar writes to when something needs confirming. Of everything on this list, it is the only check whose absence has actually taken one of my sites offline.
• A monitor of your own, pointed at the site from outside. Set it up on day one, not on the day of the first outage, because the only evidence that ever counts in a dispute is the evidence you were already collecting.

What I am not going to tell you is how any provider’s support handled an outage, including my own. I have never opened a ticket about downtime with any of them, so I have no response times to report and I am not going to manufacture an anecdote. The same rule applies across the whole site, Hostinger included.

Read the number once, then look elsewhere

Read it once, convert it to hours using the table above, then ignore it. Use it as a filter only in the crudest way: a host advertising 99% is telling you it will accept three and a half days of outage a year, and that is a real signal. Anything at 99.9% or above is table stakes and tells you nothing about which of them to pick.

Then go and find out the things that actually vary: what the renewal price is, whether anything is cached, what happens when you want to leave. Those are in the hosts I actually pay for in 2026 and what I pay for hosting, domains and email. When I have my 30 days of monitoring, the figures will appear here with the date, the interval and the location attached, and if they are unflattering they will appear anyway. That is the only version of this post worth updating.