Uptime & downtime calculator
Uptime Calculator
Free, no sign-up. We only fetch the public URL you enter.
Short answer
Enter an uptime percentage such as 99.9 and the calculator shows the allowed downtime per day, week, month, quarter and year: 99.9 % means about 1 minute 26 seconds a day, 43 minutes a month and 8 hours 45 minutes a year. Enter downtime instead, for example 45m, to get the uptime percentage that a month with that much downtime reaches — about 99.90 %. To measure your real uptime instead of calculating it, monitordefend checks your website every five minutes.
- Percentage → allowed downtime per day, week, month, quarter and year.
- Downtime per month (e.g. 45m) → resulting uptime percentage.
- Free, no sign-up, instant result.
Per day 1 min 26 s Per week 10 min 5 s Per month 43 min 48 s Per quarter 2 h 11 min Per year 8 h 45 min 36 s
Every SLA promises a percentage, but a percentage is hard to feel. This free uptime calculator translates it into time: enter 99.9 and see how many minutes of downtime that allows per day, week, month, quarter and year. It also works the other way round — enter the downtime you actually had in a month, such as 45m, and get the resulting uptime percentage. Use it to set realistic availability targets, check a hosting provider’s promise or explain an outage report in numbers everyone understands.
How to use the uptime calculator
The calculator accepts two kinds of input. Type a percentage, for example 99.9, 99.95 or 99.99, and it shows the maximum downtime that percentage allows in five time frames: per day, per week, per month, per quarter and per year. This is the number you need when you read an SLA or set a target for your own service.
Type a duration instead, for example 45m, 2h or 90s, and the calculator treats it as downtime within one month and returns the uptime percentage that month reached. That is the quick way to answer the question after an incident: we were down for 45 minutes, did we still meet 99.9 %? For 45 minutes the answer is roughly 99.90 % — just on the line.
- Percentage input: 99.9 → downtime per day, week, month, quarter, year
- Duration input: 45m, 2h, 90s → uptime percentage for one month
- Decimal point for fractions, e.g. 99.95
What is uptime?
Uptime is the share of time a system, server, website or application is operational and reachable, expressed as a percentage of a measurement period. Downtime is the rest. Both are among the most important reliability indicators, because they describe in one number what users experience: does the service work when they need it?
Uptime is usually measured from the outside, by a monitoring service that requests the website or endpoint at a fixed interval and records whether it answered correctly. The interval matters. A check every five minutes can miss an outage of two minutes; a check every hour sees only the long ones. Whatever the method, the percentage is only as accurate as the measurement behind it.
How to calculate uptime and downtime
The formula for the uptime percentage is: Uptime (%) = (total time − downtime) ÷ total time × 100. A 30-day month has 43,200 minutes; with 45 minutes of downtime it reaches (43,200 − 45) ÷ 43,200 × 100 ≈ 99.896 %.
In the other direction, allowed downtime = (1 − uptime ÷ 100) × total time. A year has 525,600 minutes, so 99.9 % allows 0.001 × 525,600 ≈ 526 minutes, or 8 hours and 46 minutes. Small differences between calculators come from the length of a month: some count 30 days, others an average month of 30.42 or 30.44 days. The table below uses one twelfth of a 365-day year; the gap is a matter of seconds.
The nines: allowed downtime table
Availability targets are often named by their number of nines. The table shows what each level allows in practice.
| Uptime | Per day | Per week | Per month | Per quarter | Per year |
|---|---|---|---|---|---|
| 99 % (two nines) | 14 min 24 s | 1 h 41 min | 7 h 18 min | 21 h 54 min | 3 d 15 h 36 min |
| 99.5 % | 7 min 12 s | 50 min 24 s | 3 h 39 min | 10 h 57 min | 1 d 19 h 48 min |
| 99.9 % (three nines) | 1 min 26 s | 10 min 5 s | 43 min 48 s | 2 h 11 min | 8 h 45 min 36 s |
| 99.95 % | 43 s | 5 min 2 s | 21 min 54 s | 1 h 5 min 42 s | 4 h 22 min 48 s |
| 99.99 % (four nines) | 8.6 s | 1 min 0 s | 4 min 23 s | 13 min 8 s | 52 min 34 s |
| 99.999 % (five nines) | 0.9 s | 6 s | 26 s | 1 min 19 s | 5 min 15 s |
What is an optimal amount of uptime?
There is no universally right number. 100 % uptime is not realistic — hardware fails, software needs updates and networks between your users and your servers break — so the useful question is how much downtime your business can tolerate and how much you are willing to pay to reduce it. Each additional nine typically requires redundancy, automation and on-call effort that cost far more than the previous one.
As a rough guide, 99.9 % is a common and achievable target for business websites, shops, blogs and most SaaS products, where a rare short outage is annoying but not dangerous. 99.99 % suits payment systems, financial services, healthcare portals and other critical online services that need multiple servers and automatic failover. 99.999 % is the territory of telecom networks, data centres and core infrastructure, where a few minutes a year is the whole budget.
The best target balances cost and impact. If an hour of downtime loses more revenue than a redundant setup costs per year, a higher target pays for itself; if not, invest the money elsewhere and aim for fast recovery instead.
Same percentage, different experience
An uptime figure says how much time was lost, not how. 43 minutes in a month can be one outage in the middle of the night that nobody noticed, or a dozen three-minute failures during peak hours that every customer felt. For users, the distribution matters as much as the sum.
Monthly error budget at 99.9 %
This is why reliability teams look at two more numbers next to uptime: mean time between failures (MTBF), which describes how often something breaks, and mean time to recovery (MTTR), which describes how long it stays broken. Uptime is roughly MTBF ÷ (MTBF + MTTR), so you can raise it either by failing less often or by recovering faster — and recovering faster is usually the cheaper lever.
Uptime in SLAs, SLOs and error budgets
A service level agreement (SLA) is a contractual promise, often with credits if the provider misses it. Read the details: which measurement period applies, whether planned maintenance is excluded, how downtime is measured and who has to report it. A 99.9 % SLA measured monthly is stricter than the same number measured yearly, because a single bad month cannot be averaged away.
Internally, many teams set a service level objective (SLO) slightly above the SLA and treat the remaining downtime as an error budget. At 99.9 % per month the budget is about 44 minutes. As long as budget is left, the team can ship changes at full speed; when it is used up, reliability work takes priority over new features. The calculator gives you the size of that budget for any target.
Estimating the cost of downtime
To estimate what downtime costs, start with the revenue that depends on the service. Divide annual online revenue by 8,760 hours to get revenue per hour, then multiply by the hours of downtime the uptime target allows. A shop with $500,000 a year online makes about $57 per hour on average; at 99.9 % uptime the 8.76 hours of allowed downtime correspond to roughly $500 of direct revenue a year.
The real figure is usually higher. Outages cluster at peak times when traffic is highest, and indirect costs come on top: support tickets, refunds, staff time, lost ad spend on campaigns that land on an error page, SLA credits and the customers who do not come back. Use the direct revenue figure as the lower bound of what reliability is worth to you.
Composite availability of dependent services
A website rarely depends on a single component. If a checkout needs the web server, the database and an external payment provider, all of them must work at the same time, and their availabilities multiply. Three components at 99.9 % each give 0.999 × 0.999 × 0.999 ≈ 99.7 % for the whole flow, which allows more than 26 hours of downtime a year instead of under nine.
- 99.9 %
Web server - 99.9 %
Database - 99.9 %
Payment provider - 99.7 %
Whole checkout
Redundancy works the other way round: two independent servers at 99 % each, either of which can serve the traffic, are only both down 0.01 % of the time, giving 99.99 %. This arithmetic is why high availability is built from redundant parts rather than from one perfect component.
How to prevent downtime
Reducing downtime combines solid infrastructure, early detection and a practised response. No single measure is enough; together they move the number.
- Choose a hosting provider with a clear SLA and a good track record
- Add redundancy: multiple servers, failover, backups that are tested
- Monitor from the outside so you learn of outages before customers do
- Plan capacity for peak traffic and sudden surges
- Deploy small changes with a quick rollback path
- Keep certificates, domains and dependencies renewed and up to date
- Write down a recovery plan and rehearse it
Measure your real uptime
The calculator shows what a target allows; only measurement shows what you achieve. monitordefend checks the homepage of each website every five minutes, confirms an outage with a second attempt, emails you and shows the uptime ratio of the selected period on the dashboard. Plans start with a 7-day free trial.
Frequently asked questions
How much downtime is 99.9 % uptime?
About 1 minute 26 seconds per day, 10 minutes per week, 43 to 44 minutes per month and 8 hours 45 minutes per year.
How much downtime does 99.99 % allow?
About 8.6 seconds per day, 4 minutes 23 seconds per month and 52 minutes 34 seconds per year.
What uptime is 45 minutes of downtime in a month?
Roughly 99.90 %. Enter 45m in the calculator to see the exact figure.
Why do calculators give slightly different numbers?
They use different month lengths — 30 days, or an average month of 30.42 or 30.44 days — and some count leap years. The differences are a few seconds per month.
Is 100 % uptime possible?
Not realistically over a long period. Every system needs maintenance and every dependency can fail; the goal is to keep downtime short, rare and outside peak hours.
Does planned maintenance count as downtime?
It depends on the agreement. Many SLAs exclude announced maintenance windows, while users experience them as downtime all the same.