Uptime SLA calculator

What this tool does

It converts an availability percentage into the downtime that percentage permits, across four periods. Nothing more complicated than that — but the arithmetic is the part almost nobody does, and the result is regularly surprising.

Uptime is expressed as the share of a period a service is reachable. A 99.9% guarantee means the provider commits to being available for 99.9% of the time, which leaves 0.1% for outages. Over a 30-day month, 0.1% is 43.2 minutes.

That figure is not an estimate of how much downtime you will get. It is the contractual ceiling before the provider owes you anything — and providers routinely run well above their guaranteed floor. What the number tells you is how much unavailability the provider considers acceptable, and that is a signal about how they operate.

Why the nines matter more than they look

Each additional nine cuts allowed downtime by roughly a factor of ten:

Two things are worth noticing.

The gap between 99% and 99.9% is enormous. Written down they look almost identical. In practice one allows most of a working day offline every month and the other allows the length of a lunch break. Budget hosts that advertise "99%" are being honest about a fairly low bar.

Above 99.99%, the number stops being about the hosting. Five nines is 26 seconds a month. No single server achieves that, because a single reboot costs more than the entire budget. Five-nines claims describe a distributed system with automatic failover — and if a provider advertises it for a single VPS, they have not thought about what they are promising.

For most business websites, 99.9% is a reasonable floor and 99.95% or better is a good sign. Below 99.9%, ask why.

What an SLA does not tell you

This is where the number becomes less useful than it appears, and where reading the actual terms matters.

Scheduled maintenance is usually excluded

Most availability guarantees carve out planned maintenance windows. A provider can take your server down for four hours on a Sunday, every month, and still report 100% uptime against the SLA — because that time was never counted.

Look for how much notice they give, whether maintenance windows are capped, and whether they are counted at all. A provider that includes maintenance in the calculation is making a much stronger commitment than one that does not.

The measurement point is the provider's

An SLA is measured by the provider's own monitoring, usually from inside their own network. That monitoring can show a healthy server while your visitors cannot reach it, because the failure is in routing, DNS, or a peering relationship rather than the machine itself.

Run your own external monitoring regardless. Free uptime checkers are adequate, and having independent data is the only way to make a credit claim you can actually support.

The remedy is usually a token

Read what happens when the SLA is missed. The typical structure is a service credit — a percentage of that month's fee, applied to a future invoice, capped at some fraction of what you pay.

If you pay $40 a month and an outage costs you a day of sales, a 10% credit is $4. The credit is not compensation and was never designed to be. It is a signal of confidence, not an insurance policy.

Also check the claim process. Many SLAs require you to submit a claim within a short window — often 30 days — with your own evidence. Credits are almost never applied automatically.

What counts as "down"

Some agreements define downtime as total unreachability only. A server that responds but takes forty seconds per request may not qualify, even though the site is unusable. Others define it per-service, so a working web server with a dead database might not count.

How to actually use the number

Three practical steps.

Set your own target first. Work out what an hour of downtime costs you — in lost sales, missed enquiries, or support load — then decide what you are willing to pay to reduce it. A brochure site and a checkout have very different answers, and the exercise takes ten minutes.

Compare the guarantee against that target. If your tolerance is two hours a month and the plan permits seven, the plan is not aligned with what you need, regardless of price.

Check whether the architecture can deliver it. A single server, however good, has a ceiling. Reboots for kernel updates, hardware failures and network events all consume the budget. If your target genuinely requires four nines, you need redundancy — two instances behind a load balancer, a database that fails over, and DNS with a short TTL — not a better single machine.

That last point is the one people skip. Buying a more expensive single server does not meaningfully improve availability; it improves performance. Availability comes from having more than one of things.

Where downtime actually comes from

Knowing the sources helps you judge whether a guarantee is realistic and where your own effort is best spent.

Planned maintenance. Kernel updates, control panel upgrades, hardware refreshes. Predictable, usually excluded from the SLA, and the largest single source on a well-run platform.

Hardware failure. A drive, a power supply, a memory module. Rare per machine, inevitable across a fleet. On virtualised platforms this is often invisible to you because the machine migrates; on dedicated hardware it is an outage.

Network and routing. A peering dispute, a fibre cut, a misconfigured route. Your server is fine and unreachable at the same time, which is exactly the case provider-side monitoring tends to miss.

Your own changes. Deploys, configuration edits, certificate expiries, a plugin update that breaks the site. On most small sites this is the leading cause by a wide margin — and it is entirely outside the provider's SLA.

That last point is worth sitting with. If you are choosing between a 99.9% plan and a 99.95% plan to gain 21 minutes a month, but a fumbled deploy takes you down for an hour twice a year, the SLA is not where your availability problem lives. Staging environments, snapshots before changes, and automated certificate renewal will do more than the upgrade.

Attack traffic. Also usually excluded. Check whether the provider mitigates a DDoS or simply null-routes your IP until it stops, because those are very different outcomes.

Comparing two plans in practice

A concrete way to use the number when the choice is close:

1. Enter both guarantees and note the monthly difference in permitted downtime.
2. Multiply that difference by what an hour offline costs you.
3. Compare the result with the price difference between the plans.
4. Then check whether the more expensive plan actually differs in architecture, or only in what it promises.

Step four matters because a stronger SLA on identical infrastructure is a commercial commitment rather than a technical one. It may still be worth paying for — it signals confidence and gives you recourse — but it will not by itself make the service more available.

A worked example

Say you run a store doing $8,000 a month, roughly $11 an hour averaged out, with sales concentrated in the evenings so peak-hour downtime costs perhaps three times that.

• A 99% plan permits 7.2 hours of downtime a month. At an average $11 an hour that is around $80 of exposure, more if outages land badly.
• A 99.9% plan permits 43 minutes — roughly $8.
• Moving from one to the other might cost $20 a month.

On those numbers the upgrade pays for itself, and that is before considering the reputational cost of a checkout that fails during a promotion. Run the same arithmetic with your figures before deciding the cheaper plan is cheaper.