An uptime guarantee is a specific commercial promise, and it is narrower than it sounds. Reading it properly tells you what you are buying, what you can claim, and, more usefully, what you still have to arrange yourself.
What the numbers mean
Uptime is quoted as a percentage per month, and the useful translation is downtime.
99% allows about 7 hours 18 minutes a month.
99.9% allows about 43 minutes.
99.99% allows about 4 minutes 20 seconds.
Each additional nine costs roughly ten times as much to deliver, which is why the difference between 99.9% and 99.99% is not a marketing detail; it is a different architecture.
Read what is excluded
This is where most of the meaning is.
Scheduled maintenance is almost always excluded, and it is when many outages actually happen. A guarantee that excludes it is measuring the unplanned half only.
Network outside their control, upstream providers, routing between you and them.
Your own software. A site down because of your plugin is not their downtime, and that is reasonable.
Attacks are frequently excluded, which matters if that is the risk you were buying protection against.
What is left is usually hardware and their own network. That is worth having, and it is a smaller promise than "99.9% uptime" implies.
What "uptime" is measured against
Often the server responding to a ping, not your website working.
A machine that answers while the web server is stopped, the database is down, or the site returns a 500 counts as up under that definition. Your visitors would disagree.
Ask what is monitored and from where. A guarantee measured by the provider, using their own definition, from inside their own network, is a different thing from one measured externally against a real page. How to Set Up and Read Uptime Monitoring explains measuring it yourself, which is the only figure you can act on.
Credits are the remedy, and you have to ask
Almost every guarantee pays out as a service credit rather than money, proportional to the downtime.
Two things follow. The compensation for an outage is a fraction of a month's hosting fee, which will not cover what an outage costs a shop. And credits are rarely applied automatically. You claim them, usually within a stated window, with evidence.
That evidence is your own monitoring. Without it, a claim is your recollection against their records.
The guarantee is not a plan
The important point, and the reason to read this at all.
An SLA distributes the cost of failure; it does not prevent failure. A four-hour outage with a credit is still a four-hour outage.
What actually reduces the impact is on your side: backups you have restored, monitoring that alerts you before customers do, and knowing in advance what you would do. What to Do When Your Website Goes Down sets out the triage.
Response time is often the more useful commitment
For most businesses, how quickly someone starts working on a problem matters more than a percentage.
Look for a stated response target, whether it differs by severity, and whether support is staffed at the hours you need. A provider answering within an hour at 3am is worth more than a fourth nine on paper.
Ask what escalation looks like when the first reply does not solve it. That is the part that decides how a bad night goes. For your half of it, see How to Write a Support Request That Gets Solved Fast.
Redundancy is what buys the extra nines
A single server has single points of failure. A disk, a power supply, a network card, the machine itself. RAID and redundant power reduce some of them and not all.
Genuine high availability means more than one machine, which changes your architecture as much as your bill: shared sessions, shared file storage, a database that is not on the web server. How to Plan Server Capacity and When to Scale sets out what that involves.
Most businesses do not need it. What is worth doing early is not making it impossible later.
Questions worth asking before signing
What exactly is measured, and from where. What is excluded, specifically. How maintenance is announced and how far in advance. How a credit is claimed and by when. What the response target is, at what hours, and how escalation works.
A provider who answers those plainly is telling you something useful about how they operate, which is more informative than the number on the page.
Measure it yourself regardless
External monitoring, checking a real page that touches the database, alerting somewhere that does not depend on this server.
That gives you your own record, tells you about an outage before a customer does, and is the evidence for any claim you make. It costs almost nothing and it is the only uptime figure that reflects what your visitors experienced.
What a guarantee cannot cover is the layer nobody made redundant. Understanding Single Points of Failure in a Server Setup walks through finding which one that is.
Work out what the number is actually worth
Converting a percentage into minutes makes the commitment concrete, and the result is usually smaller than it sounds.
Over a month, ninety nine point nine per cent permits around forty three minutes of downtime. Ninety nine point ninety five permits about twenty two. Ninety nine point nine nine permits roughly four.
Now compare that against what an outage costs you for the same period. For most small sites the honest answer is that the difference between those tiers is not worth a large price increase, and the money is better spent on backups and on a second copy of anything that cannot be rebuilt.
The guarantee is a billing arrangement rather than an engineering one. It describes what you are owed if something fails, not how likely the failure is. Understanding single points of failure deals with the part that actually changes the odds.
Keep your own record of the outages
Claiming against a guarantee requires evidence, and the provider's own status page is not evidence you control.
while true; do
printf '%s %s\n' "$(date -u +%FT%TZ)" "$(curl -s -o /dev/null -w '%{http_code} %{time_total}' https://example.com/)"
sleep 60
done >> ~/uptime.log &
grep -vc ' 200 ' ~/uptime.log
A record from outside your own network is better still, since a check running on the affected server proves nothing about whether visitors could reach it.
What matters is the timestamps. A claim naming exact periods, from a log kept continuously, is answerable. One saying the site was down a lot last month is not, and that is the difference between a credit and a conversation. Setting up and reading uptime monitoring covers the external check.
Most outages are not the ones the guarantee covers
The commitment covers the provider's infrastructure. Several common failures sit outside it entirely and are yours.
A domain that expired. A certificate that failed to renew. An account suspended for exceeding a limit. A change deployed that broke the site. A DNS edit that pointed the name somewhere wrong.
None of those is a breach of anything, and together they account for a large share of the time real sites spend unreachable. That is worth knowing when choosing between tiers, because the money spent moving from one to the next buys nothing against any of them.