What an Uptime Guarantee Really Promises

Providers advertise uptime percentages, and the numbers look like promises
that the service will not go down. They are something narrower: a definition of
the threshold below which you may claim a partial refund. Understanding the
difference changes how much weight the number deserves.

What the percentages allow

Expressed as time, the figures are less abstract:

Kamatera advertises a 99.95% uptime guarantee, which is in the range typical
for infrastructure providers. Forty three minutes a month at 99.9% is a real
outage, and it is permitted without the guarantee being breached at all.

What the agreement actually commits to

Three things are worth knowing before you rely on one.

The remedy is a service credit. If the threshold is missed,
you may receive a percentage of that month’s fee back. You do not receive
compensation for your lost revenue, your customers’ time, or the reputational
cost. The credit is proportionate to what you paid the provider, which is
usually a small fraction of what an outage cost you.

You usually have to claim it. Credits are rarely automatic.
There is a window, often short, and a required format. Most eligible credits are
never claimed because nobody files.

The exclusions are extensive. Scheduled maintenance is
typically excluded. So is anything caused by your own configuration, by
third-party services, by circumstances outside the provider’s control, and
frequently anything affecting only a single instance rather than a region.

That last exclusion matters most. Many guarantees apply to the service as a
whole rather than to your particular server, so a single machine failing may not
count towards the figure at all.

Single instances are usually excluded by design

This is the detail that most changes expectations. Several providers offer
their headline figure only for deployments spread across multiple availability
zones. A single instance in a single zone may carry a lower guarantee or none.

The implicit message is reasonable: the provider is confident the overall
service will stay available, and expects you to build redundancy if you need
your particular workload to stay available. Availability is a shared
responsibility, and the guarantee covers their half.

What to do instead of relying on it

Treat the percentage as information about the provider’s confidence, not as
protection. Then decide what you actually need.

Decide your own tolerance first. How long can you be down
before it is a serious problem? An hour, a day, five minutes? The honest answer
for many systems is longer than people assume, and that answer determines how
much redundancy is worth paying for.

Then build to that. If you need better availability than a
single server provides, run more than one across zones, as discussed in
load balancers: when you actually need
one. If a short outage is acceptable, a single server with tested backups
and a fast rebuild is a legitimate, cheaper choice.

Measure it yourself. Your own external monitoring tells you
what your users experienced, which is the number that matters and is not the
same as the provider’s status page. See
monitoring: what to watch on a single
server.

Reading one before you sign

1. What exactly is covered: the region, the service, or your instance?
2. How is downtime measured, and from whose perspective?
3. What is excluded, particularly maintenance?
4. What is the credit, and how and when must it be claimed?
5. Does the guarantee require a multi-zone deployment to apply?

If the answers do not match what you assumed, that is useful to know before
an outage rather than during one.