Uptime and SLAs explained: what 99.9% really allows

Uptime percentage is the time a service worked, divided by the total time in the period, multiplied by 100.

uptime % = (total time - downtime) / total time * 100

Every part of that formula needs a decision. What is the period? What counts as downtime? Who measures it? Those choices come later in this guide. First, the arithmetic.

A worked example

Take a 30-day month. It has 30 × 24 × 60 = 43,200 minutes.

Your site had two outages that month: one of 38 minutes and one of 12 minutes. That is 50 minutes of downtime.

(43,200 - 50) / 43,200 * 100 = 99.884%

If your target was 99.9%, you missed it. A 99.9% target allows 43.2 minutes in a 30-day month, and you used 50. You were over by 6 minutes 48 seconds.

The same formula, turned round

To find how much downtime a target allows, multiply the period by the part you are allowed to lose:

allowed downtime = total time * (1 - target)

43,200 minutes * (1 - 0.999) = 43.2 minutes = 43 minutes 12 seconds

The period changes the answer

The same 50 minutes looks very different over a year. A 365-day year has 525,600 minutes:

(525,600 - 50) / 525,600 * 100 = 99.990%

One bad month can vanish inside a good year. That is why an uptime figure with no period attached tells you almost nothing. Always ask: over how long?

A target of 99.9% allows 43 minutes 12 seconds of downtime in a 30-day month. The table gives the allowance for the six targets you are most likely to meet, over four periods.

The periods used are exact: a day is 86,400 seconds, a week is 604,800 seconds, a 30-day month is 2,592,000 seconds and a 365-day year is 31,536,000 seconds.

How to read it

• Each extra nine divides the allowance by ten. 99.9% allows 43m 12s a month. 99.99% allows 4m 19.2s. 99.999% allows 25.92s.
• The nicknames: 99.9% is "three nines", 99.99% is "four nines", 99.999% is "five nines".
• The step from 99% to 99.9% is large. It takes you from over 7 hours a month to under 44 minutes.

Month length matters a little

Months are not all 30 days. At 99.9%:

• A 28-day February allows 40 minutes 19 seconds.
• A 31-day month allows 44 minutes 38 seconds.
• An average month (a twelfth of a 365-day year) allows 43 minutes 48 seconds.

If a contract says "per calendar month", the allowance moves with the month. If it says "per 30 days", it does not. For any other target or period, the uptime calculator does the sum for you.

An SLI is a measurement. An SLO is a target for that measurement that you set for yourself. An SLA is a promise to a customer, usually in a contract, with a consequence if you break it.

The three stack on each other. You cannot have an objective without something to measure, and you should not sign an agreement without an objective you already meet.

SLI: pick something users feel

A good indicator follows what a user experiences. "The server process is running" is a poor one, because the process can run while every page returns an error. "A request to the login page succeeds within 2 seconds" is better.

SLO: your own line

The objective is the level at which the team agrees to act. Above it, you ship features. Below it, reliability work comes first. Nobody outside the team has to see it.

SLA: looser than the SLO, on purpose

Set the public promise below the private target. With an SLO of 99.95% and an SLA of 99.9%, you aim for 21 minutes 36 seconds a month and promise 43 minutes 12 seconds. The 21 minutes 36 seconds between them is your margin. A bad month can break the objective without breaking the contract.

An SLA counts only the downtime it defines as downtime, and the usual remedy is a partial credit on a later bill. Both points are in the small print, and both make the promise narrower than the headline number.

Common exclusions

Wording differs from one provider to the next, but these exclusions appear in many agreements:

• Scheduled maintenance that was announced in advance.
• Force majeure: events outside the provider's control, such as natural disasters or wide internet failures.
• The customer's own faults: a bad configuration, your own code, going over a quota, or an unpaid account.
• Third parties the provider does not run, such as your DNS host or your own network.
• Short blips. Some agreements count an outage only after it has lasted a set number of minutes.

So a service can be unreachable for you and still be "up" under the agreement. Read the definition of downtime before the percentage.

How service credits work in general

If measured uptime falls below the promise, the customer can claim a service credit. The usual pattern:

• The credit is a percentage of that month's fee, and it grows in steps as uptime falls.
• It comes off a future invoice. It is rarely a cash refund.
• You often have to ask for it, in writing, within a set number of days.
• There is a cap, often a share of the monthly fee.
• The credit is commonly stated as the only remedy for missing the target.

An invented example

These numbers are made up to show the sum. They are not any company's terms. Suppose an agreement promises 99.9% a month, with a 10% credit below 99.9% and a 25% credit below 99%. You pay 200 GBP a month.

The service is down for 2 hours in a 30-day month:

(43,200 - 120) / 43,200 * 100 = 99.72%

That is below 99.9% and above 99%, so the credit is 10% of 200 GBP: 20 GBP.

If those 2 hours cost you 3,000 GBP in lost orders, the credit covers under 1% of it. A service credit is a signal that the provider takes the target seriously. It is not insurance. Plan your own resilience around what an outage costs you, not around the credit.

Two people can measure the same service over the same month and report different uptime, and both can be right. The result depends on four choices: how often you check, where you check from, what you call "down", and how you count partial outages.

1. How often you check

A check is a sample. Between two checks you know nothing. The longer the gap, the more you miss and the rougher your figure. The next section puts numbers on this.

2. Where you check from

A check from inside your own network skips DNS, the CDN and the public internet. It can say "up" while no customer can reach you.

A check from one place outside sees what a user in that place sees. A network fault between that place and your server shows as downtime, even if everyone else is fine. An outage that only hits another region does not show at all. Know where your checks run, and read the number with that in mind.

3. What counts as down

These rules all change the result:

• Which status codes fail. A 503 is down. Is a 404 on the home page down? Is a 401 on an API? The guide to HTTP status codes goes through each.
• The timeout. A page that takes 12 seconds is "up" with a 30 second timeout and "down" with a 10 second one.
• Retries. If a check fails once and passes on the retry, did the service go down?

4. Partial outages

Real failures are rarely all or nothing. Three common cases:

• One feature is down. Checkout fails while the home page loads. A home page check reports 100%.
• One server in three is failing. About a third of requests fail. A single check passes or fails by luck.
• One region is down. Users there see a full outage. Everyone else sees nothing.

Time-based or request-based

There are two ways to turn failures into a percentage. Time-based uptime counts minutes of downtime. Request-based availability counts failed requests out of all requests.

They can disagree. Suppose a 30 minute outage happens at 03:00, when traffic is low. By time, the month is (43,200 - 30) / 43,200 = 99.93%. If only 500 of the month's 3,000,000 requests would have fallen in that half hour, the request-based figure is 99.983%.

Neither figure is wrong. They answer different questions: "how long was it broken?" and "how many users did it hurt?". Say which one you publish.

A lot, for short outages. A 5 minute interval can miss a 4 minute outage completely, and it can record a 30 second outage as 5 minutes. A 1 minute interval cuts both errors by five.

The examples below assume the common method: each failed check counts as one interval of downtime, and outages start at a random moment.

Missing an outage

Checks run at 12:00 and 12:05. The site is down from 12:00:30 to 12:04:30, which is 4 minutes. Both checks pass. Recorded downtime: zero.

The chance that a 5 minute interval catches an outage shorter than 5 minutes is its length divided by 5. A 2 minute outage is seen 40% of the time. With 1 minute checks it is always seen.

Overstating an outage

The site is down from 12:04:50 to 12:05:20, which is 30 seconds. The 12:05 check lands inside it and fails. The next check, at 12:10, passes. Recorded downtime: 5 minutes, ten times the real length.

What this does to the percentage

A 30-day month holds 8,640 checks at 5 minutes and 43,200 checks at 1 minute. One failed check is the smallest step your figure can move:

• 5 minute checks: one failure is 1 / 8,640 = 0.0116%. Uptime drops to 99.988%.
• 1 minute checks: one failure is 1 / 43,200 = 0.0023%. Uptime drops to 99.998%.

Now compare with a target. At 99.9%, the month allows 43 minutes 12 seconds. One recorded 5 minute failure uses 11.6% of that, even if the real outage lasted 30 seconds.

At 99.99%, the month allows 4 minutes 19 seconds. A single failed 5 minute check records 5 minutes and breaks the target on its own. You cannot measure four nines with 5 minute checks. With 1 minute checks, one failure uses 60 of the 259 seconds, or 23%.

Over a long period with many outages, the misses and the overstatements roughly cancel. In one month with one or two incidents, they do not. That month is the one an SLA judges.

The interval also sets how fast you find out

With 5 minute checks, an outage can run for almost 5 minutes before the first check fails. With 1 minute checks, the wait is under a minute.

PULSX checks as often as every 60 seconds. A failed check is retried 3 times, 30 seconds apart, before an alert is sent, so a single dropped packet does not page you. It is free for 20 monitors, and you can sign up without a card.

If your service needs several parts to all work at once, multiply their availabilities together. The result is always lower than the weakest part. If parts back each other up, the result is higher than the best part.

In series: every part must work

A request that needs a web server and a database fails if either one is down. With each at 99.9%:

0.999 * 0.999 = 0.998001 = 99.8%

Two parts at "three nines" give you less than three nines. Add more and it keeps falling:

The combined figures are rounded to one decimal place. The exact value for five parts is 0.999 to the power of 5, which is 99.501%.

A worked example with mixed parts

Say a checkout needs four things: your application (99.95%), your database (99.95%), your DNS provider (99.99%) and a payment API (99.9%).

0.9995 * 0.9995 * 0.9999 * 0.999 = 0.9979 = 99.79%

That allows about 1 hour 31 minutes of downtime in a 30-day month. No single part allows more than 43 minutes 12 seconds. You cannot promise your customers 99.9% on this checkout, even though every supplier meets or beats 99.9%.

In parallel: any one part is enough

If two parts do the same job and either can carry the load alone, the service fails only when both fail together. Multiply the chances of failure and subtract from 1:

1 - (1 - 0.99) * (1 - 0.99) = 1 - 0.0001 = 0.9999 = 99.99%

Two servers at 99% each give 99.99% as a pair. Two at 99.9% each give 99.9999%.

Why real systems do worse than the parallel sum

The parallel formula assumes the two parts fail independently and that switching between them is instant and perfect. Neither is fully true.

• Shared causes. Two servers in one data centre lose power together. Two copies of an application get the same bad deploy.
• The switch is a part too. A load balancer sits in series with the pair.

Put the pair of 99% servers behind a load balancer at 99.95%:

0.9999 * 0.9995 = 0.9994 = 99.94%

That allows about 26 minutes a month. It is far better than one server (7 hours 12 minutes) and well short of the ideal pair (4 minutes 19 seconds).

An error budget is the downtime your target allows, treated as an amount you can spend. It is 100% minus your SLO. With a 99.9% objective over 30 days, the budget is 43 minutes 12 seconds.

The idea changes the question. You stop asking "how do we never go down?" and start asking "how do we want to spend 43 minutes this month?". Deploys, migrations and experiments all carry risk. The budget says how much risk you can afford.

A budget in use

By 14 October the team has spent 23 minutes, which is 53% of the budget, in 47% of the window. They are spending slightly faster than the target allows. That is a reason for care with the next risky change. It is not yet a reason to stop.

What to do with it

• Budget left: ship changes at the normal pace.
• Budget nearly gone: slow down. Smaller deploys, more testing, no risky migrations.
• Budget spent: pause feature releases and work on what caused the outages until the window recovers.

Agree on these rules before you need them. A budget only works if the team accepts the pause when it comes.

Request-based budgets

The same idea works with requests. At 99.9% with 10,000,000 requests a month, you may fail 10,000 of them. This form suits services where a partial failure hurts some users and not others.

One more choice: decide whether planned maintenance spends the budget. If users cannot use the service during it, the honest answer is yes. Each incident that spends budget is worth a short written review. The guide to incident postmortems shows how.

Choose the lowest target your users are happy with, check that your dependencies and your team can meet it, and tighten it only when you have the data to show you can. A higher number is not always a better one. Each nine costs more than the one before.

1. Start from what you measure today

Look at the last 90 days. If you ran at 99.7%, a 99.99% target is a wish. Set the first objective a little above where you are and move it up as you improve.

2. Ask what users notice

An internal reporting tool used in office hours can be down at night and nobody minds. A payment page cannot. Match the target to the cost of an outage for that service. The downtime cost calculator turns an hour of outage into a money figure for your own numbers.

3. Check the ceiling your dependencies set

Run the series sum from the previous section on your own stack. If the answer is 99.79%, you cannot honestly promise 99.9% without adding redundancy.

4. Check what a person can do in the time allowed

The jump from 99.9% to 99.99% is where the work changes kind. Below it, a person fixes things. Above it, the system has to fix itself.

5. Do not pick 100%

No service reaches it over a long enough period, and a 100% target leaves no budget for any change at all. Every deploy becomes a breach.

6. Objective first, agreement later

Run an internal SLO for a few months. When you have met it steadily, offer an SLA set below it.

Publish the number together with the period, the method and the incidents behind it. A bare "99.99% uptime" badge asks for trust. A figure with its working shown earns it.

What to show next to the figure

• The period. "Last 90 days" or "October 2026". Never a figure with no dates.
• The method. What is checked, how often and from outside or inside your network.
• Each component on its own line. Website, API and dashboard each get a figure. One blended number hides the part that failed.
• The incidents. A dated list with durations, so a reader can add them up and reach your figure.
• Maintenance. Say whether planned work is counted in the figure, and list it either way.

Habits that make a figure dishonest

• Rounding up. 99.94% is not 99.95%, and 99.996% is not 100%. Show two decimal places and round down.
• Counting partial outages as up. If checkout was broken for an hour, the hour counts for checkout.
• Quietly removing incidents, or restarting the period after a bad month.
• Measuring from inside. A health check that runs on the server itself cannot see a DNS or network outage.
• More decimals than the data supports. With 5 minute checks, one failed check moves a monthly figure by 0.0116%. A third decimal place is noise.

An example of a good line

"API: 99.96% over the last 90 days, measured by an outside HTTP check every 60 seconds. Includes 2 incidents totalling 50 minutes. Does not include 2 announced maintenance windows totalling 40 minutes."

A reader can check that. Ninety days is 129,600 minutes, and (129,600 - 50) / 129,600 is 99.961%, shown as 99.96%.

During an incident

The uptime figure is history. While something is broken, users want the current state: what is affected, since when, and when you will say more. A status page with dated updates does that job. The status page guide covers what to put on one.

PULSX includes public status pages with subscribers, themes and announcements, plus maintenance windows.