Uptime & SLA Calculator

See how much downtime an SLA allows, convert outage duration into an uptime percentage, and combine the uptime of the services you depend on to calculate overall availability.

PeriodAllowed downtimeCost of that downtime
Per day1m 26s–
Per week10m 5s–
Per month43m 48s–
Per quarter2h 11m 24s–
Per year8h 45m 36s–

An outage can run for up to 5m before the next check catches it. That's 11% of your 43m 48s monthly downtime budget gone before anyone is alerted.

Month length and maintenance windows

A year is 365 days here, and a month is a twelfth of that (about 30.4 days). Costs are hours of downtime times revenue per hour.

Downtime allowed by common SLA uptime percentages

Each extra nine cuts the allowed downtime by a factor of ten. Here's what the most common SLA targets work out to, using the same 365-day year as the calculator above.

Uptime Per day Per week Per month Per quarter Per year
99% (two nines)14m 24s1h 40m 48s7h 18m21h 54m3d 15h 36m
99.5%7m 12s50m 24s3h 39m10h 57m1d 19h 48m
99.9% (three nines)1m 26s10m 5s43m 48s2h 11m 24s8h 45m 36s
99.95%43s5m 2s21m 54s1h 5m 42s4h 22m 48s
99.99% (four nines)8.6s1m4m 23s13m 8s52m 34s
99.999% (five nines)0.9s6s26s1m 19s5m 15s

The jump from 99.9% to 99.99% is bigger than it looks. Three nines leaves room for a botched deploy and a quick rollback every month. Four nines gives you about four minutes, which usually means automated failover and no manual steps in the recovery path.

How to calculate uptime percentage

Uptime is the share of a period when the service was available:

Uptime= total time−downtime total time ×100%

So 30 minutes of downtime in a 30-day month (43,200 minutes) works out to about 99.93% uptime. Going the other way, the downtime an SLA allows is the part of the period it doesn't promise:

Allowed downtime= (1− SLA100 ) ×period

The math is the easy part. The harder questions are what counts as "down" and over which period. Some things worth settling before you sign or publish an SLA:

  • Calendar month or rolling 30 days? A 31-day month allows a little more downtime than February does. The calculator averages it out by default, and you can pick an exact month length under its options.
  • Does scheduled maintenance count? Many SLAs exclude announced maintenance windows, which can make a 99.9% promise much easier to keep than it sounds. The calculator's options let you exclude a weekly or monthly window.
  • Is a partial outage downtime? If the homepage loads but checkout fails, a simple ping check says you're up. Your customers probably disagree.
  • How often do you check? A check every five minutes can miss a three-minute outage entirely, which matters a lot when a four-nines budget is only about four minutes a month. The calculator shows how much of the budget a given check interval can burn before you hear about it.

Calculating combined availability across dependencies

A typical site depends on a chain of services: a CDN, a load balancer, the app itself, a database, and a payment or auth API. If a request needs all of them, they're in series, and their availabilities multiply:

Acombined= A1× A2× ⋯× An
where each A is a dependency's availability as a fraction, so 99.9% is 0.999

Three dependencies at 99.9% each come out to about 99.7%, which is roughly 26 hours of downtime a year instead of 8¾. Every dependency you add pulls the total down, so it's hard to promise customers more than your weakest vendor promises you.

Redundancy pushes the other way. When any one of several copies can serve traffic, the service is only down when all of them are:

Aredundant= 1− (1−A)n
where A is the availability of one copy and n is the number of copies

Two independent 99.9% instances reach about 99.9999% between them. That math assumes the copies fail independently, though. Two servers in the same region, behind the same load balancer, or running the same bad deploy tend to go down together, so real redundancy usually lands well short of the formula.

How to calculate the cost of downtime

The calculator's cost estimate is hours of downtime multiplied by revenue per hour. If your site does $2.4M a year in online sales, that's roughly $274 an hour averaged across the year, so a three-nines month (43m 48s of downtime) costs about $200.

That average usually understates the real cost. Outages are more likely during deploys and traffic peaks, and an hour down on Black Friday or during a product launch costs far more than an hour down at 3am. If you know your peak-hour revenue, try that number as well to see the range.

Revenue also isn't the only cost. Support tickets, SLA credits, engineering time spent firefighting, and customers who quietly don't come back are harder to put a number on, but they're often bigger than the lost sales.

SLA vs SLO vs SLI: what's the difference

SLI

The service level indicator is what you measure, such as the percentage of successful checks or requests.

SLO

The service level objective is your internal target for that measurement, like 99.95% over 30 days.

SLA

The service level agreement is the promise to customers, usually looser than the SLO and backed by credits.

Teams typically set the SLO a bit tighter than the SLA, so they hear about trouble while there's still some error budget left, before customers are owed anything.

Measuring uptime with synthetic monitoring

An uptime number is only as good as the checks behind it. Synthetic monitoring runs scripted checks against your site on a schedule, from several locations, and records each failure. Those failures are your downtime, and they're what you'd compare against the budget from the calculator above.

Loadster's synthetic monitoring can run a simple uptime check, or a full user journey like logging in and checking out in a real browser, so a broken checkout counts as downtime even when the homepage is fine. The synthetic monitoring guide covers what to check and how often.

This calculator is one of the free tools from the Loadster team, along with the website speed test.

Find out how much of your downtime budget you're really using

The calculator tells you how much downtime you can afford. Loadster monitoring measures your actual uptime, alerting your team of issues so you can react quickly.

  • Checks as often as every minute, from 8 global locations
  • Real Chrome browsers to test critical flows, not just pings
  • Alerts by email, SMS, phone, PagerDuty, Opsgenie, or webhook
  • Uptime history and hosted status pages
Start Monitoring Uptime

Try for free with 50 units of Loadster Fuel. No credit card required.

Loadster monitor showing pass rate, failed cycles, and response time history

Frequently Asked Questions

How much downtime does 99.9% uptime allow?
99.9% uptime (three nines) allows about 43 minutes and 48 seconds of downtime per month, 10 minutes and 5 seconds per week, and 8 hours and 45 minutes per year. That assumes a 365-day year with each month as a twelfth of it.
How much downtime does 99.99% uptime allow?
99.99% uptime (four nines) allows about 4 minutes and 23 seconds of downtime per month, or 52 minutes and 34 seconds per year. That’s short enough that a single slow deploy or failover can use up a whole month’s budget.
How do you calculate uptime percentage?
Divide the time the service was up by the total time in the period, then multiply by 100. For example, 30 minutes of downtime in a 30-day month (43,200 minutes) is (43,200 − 30) ÷ 43,200 × 100, or about 99.93% uptime.
How do you calculate the combined availability of several services?
If your site needs every one of its dependencies to be up, multiply their availabilities together. Three services at 99.9% each give 0.999 × 0.999 × 0.999, or about 99.7% combined, which is roughly 26 hours of downtime a year. Redundant copies work the other way: two 99.9% instances where either one can serve traffic are only down when both are, so the pair reaches about 99.9999%.
How do you calculate the cost of downtime?
A simple estimate is hours of downtime multiplied by the revenue your site brings in per hour. It’s a floor more than an exact figure, since outages tend to hit during busy periods, and lost trust, support load, and SLA credits don’t show up in the revenue math.
What's the difference between an SLA, an SLO, and an SLI?
An SLI (service level indicator) is the measurement itself, like the percentage of successful checks. An SLO (service level objective) is the internal target for that measurement, like 99.95%. An SLA (service level agreement) is the promise you make to customers, usually a little looser than the SLO and backed by credits or refunds if you miss it.
How do I actually measure my site's uptime?
Run synthetic checks against the site on a schedule from more than one location, and count the failed checks as downtime. A check that only loads the homepage can miss outages in login or checkout, so scripted multi-step checks give a more honest uptime number.