This post is about doing that translation properly, and about two details that quietly change what an uptime number means: how long "a month" is, and how often you actually measure.

The basic conversion

Allowed downtime is just the complement of the target, multiplied by the period:

allowed_downtime = (1 - uptime / 100) × period

Using an average month of 30.44 days (so twelve months add up to 365.2425 days), the common targets work out like this:

Two patterns are worth memorising. Each extra nine cuts allowed downtime by a factor of ten. And the jump from 99.9% to 99.99% is where things stop being "be careful with deploys" and start being "you need redundancy across failure domains", because 4 minutes a month is less than one slow rollback.

Which month?

Contracts rarely say. If an SLA is evaluated per calendar month, a 31-day month allows slightly more downtime than February. For 99.9%, that's about 44.6 minutes in a 31-day month versus 40.3 in a 28-day one. Not huge, but if you're arguing about a credit, compute it from the daily figure (1 min 26 s at 99.9%) times the actual number of days.

Your measurement has a resolution

Here's the part that trips people up. Uptime isn't observed continuously; it's sampled. If you check every 5 minutes, an average month contains about 8,766 checks. At 99.9%, that leaves room for roughly 8 failed checks.

That has consequences:

• Short outages can be invisible. A 3-minute blip between two checks never shows up. Your users saw it; your dashboard didn't.
• One failed check can be "worth" 5 minutes. A 20-second hiccup that happens to coincide with a check counts as a whole interval.
• Five nines is unmeasurable at 5-minute resolution. 26 seconds a month is less than one sample. If you sell 99.999%, you need far finer checks, and from more than one place.

So when you read an uptime figure, ask what produced it: how often, from where, and what counted as a failure.

Define "down" before you count it

Two monitors can watch the same service and report different uptime simply because they define failure differently. A reasonable, explicit definition might be:

• Down: DNS fails, the connection is refused or times out, TLS fails, or the server returns a 5xx error such as 500, 502 or 504.
• Degraded: the server answers, but with 503, an invalid certificate, or only after several seconds.
• Up: any answer at all, including 403 or 429, since those prove the server is reachable.

Also decide whether to retry before recording a failure. Retrying once after a couple of seconds filters out single dropped packets and makes the number reflect real incidents rather than network noise.

Exclude user-triggered checks

If people can trigger checks on demand ("is it down right now?"), keep those out of your uptime calculation. Users check far more often when something already looks broken, so including them skews the number downward in exactly the periods that matter. Scheduled checks at a fixed interval are the only fair denominator.

Maintenance is a contract question

Does planned maintenance count? That depends entirely on the agreement. Many SLAs exclude maintenance announced in advance, and each defines downtime its own way. A plain calculator counts every second, so read the definition before comparing your measured number with what a provider promised.

Error budgets: using the number

The most useful thing about the conversion is that it gives teams a budget. If your target is 99.9% and you've already spent 30 of your 43 minutes this month, that's a clear, non-political signal to slow risky releases. If you've spent 2, you have room to ship.

Write the budget in minutes, not percentages. "We have 13 minutes left" changes behaviour. "We're at 99.93%" doesn't.

A quick tool

If you'd rather not redo the arithmetic each time, the free uptime and SLA calculator on upordown.online takes any percentage with any number of decimals and returns the allowed downtime per day, week, month, quarter and year, using the same 30.44-day month described above.

Checklist before you sign (or write) an SLA

1. Convert the percentage into minutes per month and per year.
2. Confirm the evaluation period: calendar month, rolling 30 days, or quarter.
3. Ask what counts as downtime, and whether partial failures count.
4. Ask how it's measured: interval, locations, retries.
5. Check how maintenance windows are treated.
6. Compare against what you can actually observe with your own monitoring.

Nines are a promise about minutes. Do the conversion, agree on the definitions, and the number starts meaning something.