Uptime Calculator: SLA Calculator and Downtime Calculator for 99.9% to 99.999%
Type any uptime target and see exactly how much downtime it buys you per day, week, month and year. Then work backwards: enter the minutes you were actually down and get the percentage you can honestly publish.
Uptime calculator
LiveDowntime allowed
Allowances are calculated on a 365 day year, so the day, week, month and year figures all agree with each other. Contracts that define a month as exactly 30 days give slightly smaller monthly allowances.
In short
A 99.9% uptime SLA allows 1 minute 26 seconds of downtime per day, 43 minutes 48 seconds per month and 8 hours 45 minutes 36 seconds per year. Every extra nine cuts that allowance by a factor of ten: 99.99% permits 52 minutes 34 seconds a year, and 99.999% permits 5 minutes 15 seconds. The formula is downtime = period length x (100 - uptime percentage) / 100. Use the calculator below for any percentage, or read the exact allowance for every common SLA level in the table.
Every level
Uptime percentage to downtime, for every common SLA level
Read across from your target to see the maximum downtime that target permits. Every figure is derived from a 365 day year, so the week, month and quarter columns are consistent with the annual number rather than rounded independently.
| Uptime SLA | Also called | Per day | Per week | Per month | Per quarter | Per year |
|---|---|---|---|---|---|---|
| 90% | One nine | 2h 24m | 16h 48m | 3d 1h | 9d 3h | 36d 12h |
| 95% | 1h 12m | 8h 24m | 1d 12h 30m | 4d 13h 30m | 18d 6h | |
| 98% | 28m 48s | 3h 21m 36s | 14h 36m | 1d 19h 48m | 7d 7h 12m | |
| 99% | Two nines | 14m 24s | 1h 40m 48s | 7h 18m | 21h 54m | 3d 15h 36m |
| 99.5% | 7m 12s | 50m 24s | 3h 39m | 10h 57m | 1d 19h 48m | |
| 99.8% | 2m 53s | 20m 10s | 1h 27m 36s | 4h 22m 48s | 17h 31m 12s | |
| 99.9% | Three nines | 1m 26s | 10m 5s | 43m 48s | 2h 11m 24s | 8h 45m 36s |
| 99.95% | 43s | 5m 2s | 21m 54s | 1h 5m 42s | 4h 22m 48s | |
| 99.99% | Four nines | 9s | 1m | 4m 23s | 13m 8s | 52m 34s |
| 99.995% | 4s | 30s | 2m 11s | 6m 34s | 26m 17s | |
| 99.999% | Five nines | 1s | 6s | 26s | 1m 19s | 5m 15s |
| 99.9999% | Six nines | under 1s | 1s | 3s | 8s | 32s |
The pattern worth memorising is that each additional nine divides the allowance by ten. Going from 99% to 99.9% takes you from three and a half days a year to under nine hours. Going from 99.9% to 99.99% takes you from nine hours to fifty-two minutes. The percentages look almost identical written down, which is exactly why they are useful in marketing copy and dangerous in a contract.
Measure it
Now find out what uptime you are actually getting
The number in the table is a target. The number that matters is the one your service produces, and you cannot know it without checking. Run a live check on any URL below, then set up continuous monitoring from six regions if you want the figure tracked properly.
Checked from regions with auto-retry. No single-location false alarms.
All systems operational. Steady pulse across every region.
api.example.com returned no response from all 6 regions. Auto-retry confirmed the outage, then we alerted your team.
api.example.com is back up. The incident is logged to your status page history automatically.
90-day uptime · branded · your domain
Live demo · drive it, no signup needed
The math
How to calculate uptime percentage
Uptime percentage is successful time divided by total time. Written out:
Uptime % = ((total period - downtime) / total period) x 100
Rearranged to answer the more common question, which is how much downtime a target permits:
Allowed downtime = total period x (100 - target %) / 100
The units cancel, so it works in seconds, minutes or hours as long as you use the same unit on both sides. A worked example on a 30 day month, which is 43,200 minutes: if you were unavailable for 22 minutes, that is (43200 - 22) / 43200 x 100 = 99.949%. You missed a 99.95% commitment by about half a minute and stayed comfortably inside 99.9%.
Going the other way for the same month at a 99.99% target: 43200 x (100 - 99.99) / 100 = 4.32 minutes, or 4 minutes and 19 seconds. That is the entire budget, and it is less time than most teams take to acknowledge an alert.
In practice uptime is not measured against wall clock time at all. It is measured as successful checks divided by total checks, because that is what a monitoring system can actually observe. With 1 minute checks the two are close enough to be interchangeable. With 5 minute checks they are not, which is the single most under-appreciated detail in this whole subject: your check interval is the resolution limit on your uptime figure. A tool that looks every 5 minutes cannot detect a 90 second outage, and cannot meaningfully verify anything tighter than about 99.9%.
Work backwards
What your downtime this month actually scores
Most people arrive at this page from the other direction: an incident happened, it lasted a while, and someone needs to know whether the SLA held. These are the common outage lengths converted back into a percentage, on a 30 day month.
| Downtime in the month | Uptime achieved | Where that lands |
|---|---|---|
| 30 seconds | 99.9988% | Comfortably inside a 99.99% SLA |
| 2 minutes | 99.995% | Inside 99.99%, with roughly half the month gone |
| 5 minutes | 99.988% | Missed 99.99%, comfortably inside 99.95% |
| 15 minutes | 99.965% | Missed 99.95%, inside 99.9% |
| 30 minutes | 99.93% | Inside 99.9%, with two thirds of the budget spent |
| 45 minutes | 99.90% | Right on the 99.9% line |
| 2 hours | 99.72% | Missed 99.9%, inside 99.5% |
| 8 hours | 98.9% | Missed 99%, one bad day |
One number in that table does the most damage in real incidents: 15 minutes. A quarter of an hour feels like a minor blip, the kind of thing that gets a shrug in standup, and it has already broken a 99.95% commitment for the month. If you have promised anything above 99.9% to a customer, the cost of finding out slowly is measured in tiers, not in minutes. That is the argument for continuous uptime monitoring rather than a status check somebody runs when a complaint arrives.
Reality check
What each uptime tier actually takes to run
Picking a target is easy. Paying for it is the part that decides whether the number in your contract is real. Here is roughly what sits behind each level.
99% and below
A single server, manual deploys, someone notices when it breaks
Three and a half days of downtime a year is a lot, but plenty of internal tools and early-stage products genuinely live here and nobody minds. You do not need an SLA at this level. You need to know when it happens.
99.9%
Managed hosting, health checks, external monitoring, one person on call
The realistic target for most SaaS products and the level most vendors publish. Forty-four minutes a month sounds generous until one bad deploy eats it in a single afternoon. Detection speed is what protects this budget, which is why check interval matters more than anything else in your monitoring tool.
99.95%
Redundant app servers, automated rollback, alerting that actually pages someone
Twenty-two minutes a month. You can no longer absorb a slow human response. The gap between an outage starting and a person being notified has to be under two minutes, or you have spent the budget before anyone opens a laptop.
99.99%
Multi-zone redundancy, automated failover, a real on-call rota
Four minutes and twenty-three seconds a month. No human can respond that fast, so the recovery has to be automatic. Almost every published 99.99% SLA is backed by failover, not by people. This is where infrastructure cost jumps sharply.
99.999%
Multi-region active-active, no single points of failure anywhere
Twenty-six seconds a month. In practice this means no maintenance windows, no single database primary, and a deployment process that cannot take the system down. Very few web products need it, and the ones that publish it usually exclude a great deal from the measurement.
Read the fine print
What an uptime percentage quietly leaves out
The arithmetic above is exact. What it measures is not, and the gap between the two is where most SLA disputes live.
Scheduled maintenance is usually excluded
Most commercial SLAs subtract planned maintenance windows before calculating availability. A vendor can take the service down for four hours on a Sunday every month and still report 100% uptime, because the contract says that time does not count. Read the exclusions before you read the number.
The measurement interval sets the floor on precision
If a service is checked every 5 minutes, the shortest outage it can record is 5 minutes. That is already more than a whole month of a 99.99% budget. A tool checking every 5 minutes cannot meaningfully verify a 99.99% SLA, no matter what it displays.
Partial degradation often counts as up
A page that loads in 30 seconds, an API returning errors on one endpoint, or a checkout that fails for one payment method will typically be recorded as available. Availability is usually a binary measurement of one request, which is why keyword checks and per-endpoint API checks catch what a plain ping misses.
One region down is not always counted
If availability is measured from a single location, an outage that only affects users in one part of the world may never appear. Checking from several regions and confirming a failure from a second region before alerting is what separates a real number from a comfortable one.
SLA credits rarely cover the actual loss
The standard remedy is a percentage of that month's fee, capped, and you usually have to claim it within a fixed window. A 10% credit on a $200 bill does not compensate a day of lost orders. The SLA is a signal of engineering confidence, not an insurance policy.
Your uptime is the product of everything in the chain
If your host promises 99.99%, your CDN 99.99% and your payment provider 99.95%, your realistic ceiling is the three multiplied together, about 99.93%. Availability compounds downward. Every dependency you add lowers the number you can honestly publish.
If you publish an SLA to your own customers, the last point is the one to plan around. Availability compounds downward through every dependency, so the honest way to set a target is to multiply the published figures of everything you rely on and then commit to something below the result. Our SLA monitoring pages cover how to track that continuously, and the error budget guide turns the leftover allowance into something a team can actually plan sprints against.
FAQ
Questions people ask about uptime and SLA percentages
99.9% uptime means the service is allowed to be unavailable 0.1% of the time. That works out to 1 minute 26 seconds a day, 43 minutes 48 seconds a month and 8 hours 45 minutes 36 seconds a year. It is the most commonly published SLA level for web applications and hosting.
99.99% uptime allows 4 minutes 23 seconds of downtime per month and 52 minutes 34 seconds per year, or about 9 seconds a day. That is ten times less than 99.9%. At this level a human cannot respond fast enough, so the recovery has to be automatic failover rather than someone being paged.
Uptime percentage = (total time minus downtime) divided by total time, multiplied by 100. For a 30 day month that is 43,200 minutes. If you were down 22 minutes, the calculation is (43200 - 22) / 43200 x 100, which is 99.949%. To go the other way, multiply the period by (100 minus your target) and divide by 100.
One nine, which is a factor of ten in allowed downtime. 99.9% permits 8 hours 46 minutes of downtime a year and 99.99% permits 52 minutes. The practical difference is bigger than the arithmetic: 99.9% can be reached with good monitoring and a person on call, while 99.99% requires redundancy and automated failover.
Five nines means 99.999% availability, which allows 5 minutes 15 seconds of downtime per year and about 26 seconds per month. It requires multi-region redundancy with no single points of failure and no maintenance windows. Telecoms and payment infrastructure target it. Most web products do not need it and cannot justify the cost.
99.9% uptime allows 8.76 hours of downtime per year, which is 8 hours 45 minutes and 36 seconds on a 365 day year. Per quarter that is 2 hours 11 minutes, per month 43 minutes 48 seconds, and per week 10 minutes 5 seconds.
For most web applications, yes. It is the standard commercial SLA level and it is achievable with redundant hosting, health checks and monitoring that detects failures within a minute. It stops being good enough when a minute of downtime costs real money, at which point 99.95% or 99.99% becomes the target.
By making a request to the service on a fixed interval from an external location and recording whether it succeeded. Availability is then successful checks divided by total checks. The interval sets the precision: 1 minute checks can resolve a 1 minute outage, and 5 minute checks cannot. Confirming a failure from a second region before counting it removes false positives.
Uptime % = ((total period - downtime) / total period) x 100. Rearranged for the allowance, downtime = total period x (100 - target %) / 100. Both sides of that are what the calculator on this page runs, and the units cancel, so it works with minutes, hours or seconds as long as you stay consistent.
Usually not. Most commercial SLAs explicitly exclude announced maintenance windows from the availability calculation, so a vendor can be genuinely unreachable and still report the number it promised. Check the exclusions clause, because it often matters more to your users than the headline percentage does.
Last updated August 2026
Keep reading
Where to go from here
If you have picked a target and now need something to hold you to it, the uptime monitoring tools comparison rates thirteen tools on check interval, alerting and regions, and the uptime monitoring pricing comparison shows what each of them charges with every figure read off the vendor's own page. Teams whose SLA promise is customer-facing usually need a public page as well, which is covered in status page software. For API-backed products, the API monitoring tools comparison and our API response time benchmarks deal with the latency half of availability, since an endpoint that answers in 30 seconds is technically up and practically down. If you are still deciding what monitoring is for, start with what uptime monitoring is.
A target you cannot measure is a wish
Uptimehub checks your sites, APIs and services every minute from six global regions, confirms a failure from a second region before it alerts you, and keeps 90 days of uptime history you can show a customer. From $9 a month, priced per monitor and never per seat.