How to read an uptime SLA properly

Uptime service level agreements are quoted constantly and read rarely. The headline number is treated as a quality rating, when it is really the definition of a refund threshold.

Reading one properly takes about ten minutes and changes how much weight you give it.

What the numbers mean in time

Availability percentages compress into small-sounding differences that are large in practice.

• 99% allows about 7 hours 18 minutes of downtime per month.
• 99.9% allows about 43 minutes and 48 seconds per month.
• 99.95% allows about 21 minutes and 54 seconds per month.
• 99.99% allows about 4 minutes and 23 seconds per month.
• 99.999% allows about 26 seconds per month.

Each additional nine costs roughly an order of magnitude more to deliver, which is why the gap between 99.9% and 99.99% in a price list is often substantial.

The three questions that actually matter

What is being measured? This is the most important question and the least often asked. An SLA on a virtual machine typically covers whether the instance is running and reachable from outside, not whether your application inside it is working. If your process crashes, the machine is up and the SLA is satisfied. Storage, networking and managed services usually have separate SLAs with separate definitions.

What counts as downtime? Definitions vary enormously. Some providers count only a total loss of connectivity. Some count degraded performance below a threshold. Some measure in five-minute intervals, meaning a two-minute outage may not register at all. Some require the failure to affect multiple availability zones before it counts.

What are the exclusions? Every SLA has them, and they are frequently broad: scheduled maintenance announced in advance, problems caused by your own configuration, force majeure, issues with third-party software, suspension for non-payment, and anything caused by exceeding documented limits. Scheduled maintenance in particular is often excluded entirely, which means the effective availability you experience can be lower than the number implies.

What you actually get when it is breached

Almost universally: a service credit, calculated as a percentage of the fees paid for the affected service in the affected period, applied against a future invoice.

Three practical consequences follow.

It is capped at what you paid. If an outage costs you far more in lost business than the monthly fee for the affected instance, the credit does not come close to covering it.

You usually have to claim it. Credits are rarely automatic. There is typically a window, often thirty days, within which you must submit a claim with evidence. Miss the window and there is nothing.

You need your own evidence. The claim generally requires logs or monitoring data demonstrating the outage from your side. If your only monitoring runs on the affected infrastructure, you will not have it.

That last point is the reason to run at least one external uptime check per public service, regardless of provider.

Reading it as a signal rather than a guarantee

Given the credits are small and the exclusions broad, what is an SLA actually good for?

It is a reasonable signal of engineering confidence. A provider offering 99.99% on a single instance is making a different statement than one offering 99.9%, because they have modelled their own failure rates and priced the risk.

It is also a useful comparison tool if, and only if, you compare the definitions rather than the numbers. Two providers quoting 99.99% with different measurement intervals and different exclusion lists are not offering the same thing.

Composing SLAs across a stack

This is where the arithmetic surprises people. When your application depends on several components in series, and any one of them failing takes you down, the availabilities multiply.

Three components each at 99.9% give a combined figure of roughly 99.7%, which is about double the downtime of any single component. Add a fourth and it degrades further.

Two consequences follow, and they are the practical heart of the matter.

Reduce the number of things that can independently take you down. Every additional dependency in the critical path lowers the ceiling.

Add redundancy where it counts. Two components in parallel, either of which can serve, multiply in the other direction. This is why load balancing across instances improves availability far more than choosing a provider with one extra nine.

Your architecture determines your availability far more than your provider’s SLA does. A single instance behind no redundancy will not achieve four nines no matter what the contract says, because the SLA does not cover your application crashing, your disk filling, or your certificate expiring.

A short checklist before signing

• Which specific components are covered, and which are not?
• How is downtime defined, and over what measurement interval?
• What is on the exclusion list, and is scheduled maintenance among them?
• Is the credit automatic or claimed, and what is the claim window?
• What evidence must you supply, and are you collecting it today?
• What is the maximum credit, and how does it compare with an hour of your downtime?

If the last answer is uncomfortable, the response is not a better SLA. It is redundancy, backups and a tested recovery procedure, because those change the outcome rather than the compensation.

Where you run this matters less than how, but if the provider is still open, the cloud account catalogue compares the options side by side.

For the vendor’s own reference on the services involved here, see the UpCloud documentation.

Reading about storage behaviour only goes so far; measuring it on a live server goes further. We stock UpCloud accounts in a single configuration, and the cloud account catalogue covers nine other providers.

Questions people ask