Uptime is the share of time a system is running and usable, usually given as a percentage of a period such as a month or a year. For a website, it is the share of time visitors can reach it and get a correct response: 99.9% uptime allows about 43 minutes of downtime in a 30-day month.
What does uptime mean?
Uptime is the time a system is working, and downtime is the time it is not. Most of the time the word is used as a percentage of a period: a website with 99.9% uptime last month was available for 99.9% of that month's minutes. Who is using the word changes what it means, though.
- Server uptimeOn a single machine, uptime is how long it has been running since its last restart; the uptime command on Linux and macOS prints exactly that. A server can run for a year without a reboot while the website on it is broken.
- Website and API uptimeFor a website or API, uptime is the share of time users can reach it and get a correct response. It has to be measured from outside, because a running server can still be unreachable behind a wrong DNS record, an expired certificate or a failed load balancer.
- Uptime in an SLAIn a contract, uptime is whatever the agreement defines: the measurement method, the period and which events are excluded. Two SLAs that both say 99.9% can allow very different amounts of real downtime.
The rest of this guide uses the website meaning, because that is the one your customers feel.
How do you calculate uptime percentage?
The formula is: uptime % = (total time − downtime) ÷ total time × 100.
A worked example: a 30-day month has 30 × 24 × 60 = 43,200 minutes. If your site was down for 50 minutes in that month, uptime is (43,200 − 50) ÷ 43,200 × 100 = 99.88%. Fifty minutes, one bad deploy and a slow rollback, is enough to miss a 99.9% target, which allows 43.2 minutes.
Monitoring tools usually work from checks rather than minutes: uptime is the share of checks that passed. A monitor checking once a minute makes 43,200 checks in a 30-day month. If 30 of them failed, uptime is (43,200 − 30) ÷ 43,200 × 100 = 99.93%. The two methods only agree when checks are frequent: a monitor that checks every five minutes can miss a three-minute outage entirely and report a perfect month.
99.9% per month and 99.9% per year are different promises. A yearly target lets the whole budget, almost nine hours, land in a single outage. A monthly target caps any one month at about 43 minutes.
Uptime percentages and allowed downtime (the nines)
Each extra nine cuts the allowed downtime by a factor of ten. The figures below use a 30-day month (43,200 minutes) and a 365-day year (525,600 minutes).
- 99% (two nines)7 hours 12 minutes per month; 87 hours 36 minutes (about 3.65 days) per year.
- 99.5%3 hours 36 minutes per month; 43 hours 48 minutes (about 1.8 days) per year.
- 99.9% (three nines)43 minutes 12 seconds per month; 8 hours 45 minutes 36 seconds per year.
- 99.95%21 minutes 36 seconds per month; 4 hours 22 minutes 48 seconds per year.
- 99.99% (four nines)About 4 minutes 19 seconds per month; about 52 minutes 34 seconds per year.
For any other target, the free SLA uptime calculator at sutramx.com/tools/sla-uptime-calculator converts a percentage into allowed downtime per day, week, month, quarter and year.
What counts as downtime?
The formula is the easy part. Deciding what goes into the downtime column is where most arguments, and most SLA disputes, come from.
- Full outagesThe site does not load at all, from anywhere. Nobody argues about these.
- Partial outagesLogin works but checkout fails, or the site is down in one region only. Whether that counts depends on what you measure. Checking each critical path separately stops a broken checkout hiding behind a working home page.
- Degraded performanceA page that takes twelve seconds to load is technically up. Many teams set a response-time limit beyond which a check counts as failed, because to a user slow and down feel the same.
- Planned maintenanceMany SLAs exclude announced maintenance windows, but only when the exclusion is written down in advance. Your users still experience it as downtime.
- What the monitor cannot seeA failure between two checks, or on a path nobody checks, never reaches the calculation. A reported 100% means no check failed, not that nothing did.
On a monitor's own page, checks during a maintenance window are left out of the uptime percentage, and degraded checks (reachable but slower than your threshold) count as up. SLO tracking and weekly reports are stricter: they count degraded checks as failures and include maintenance time, so they can show a slightly lower figure for the same monitor.
What is a good uptime percentage?
There is no universal number. The right target depends on what an hour of downtime costs you and how much engineering you can put into avoiding it. As a rough guide:
- 99% to 99.5%: fine for internal tools, staging environments and personal sites. It still allows hours of downtime a month.
- 99.9%: a common target for business websites and SaaS products. About 43 minutes a month leaves room for one short incident or a slow deploy.
- 99.95% to 99.99%: for payments, login and infrastructure other systems depend on. Four nines leaves about four minutes a month, less than most teams need to acknowledge a page, so it takes automated failover rather than faster people.
Two cautions. Measure before you promise: set a public target only after a quarter of real data shows you can hold it. And treat 100% as a sign that something is not being measured, not as a goal; the SLA, SLI and SLO guide explains why. For reference, SutramX's own published monthly uptime target for its Growth and Pro plans is 99.9%.
Uptime vs availability vs reliability
- UptimeThe share of time the system was up and reachable, measured against the clock.
- AvailabilityWhether the service did its job when someone asked, often measured as successful requests divided by all requests. A site can be up while returning errors to half its users; request-based availability shows that, a simple up-or-down clock does not.
- ReliabilityThe broader property of working correctly over time: how often things fail and how quickly they recover. One 43-minute outage and 43 one-minute blips both give 99.9% for the month, but they feel very different to users and call for different fixes.
In everyday use uptime and availability are often treated as the same thing, and contracts frequently say availability while defining it with an uptime-style calculation. What matters is that the definition is written down.
How do you measure uptime?
Measure from outside your own infrastructure. Your server logs cannot record the requests that never reached the server, and those are exactly the ones an outage produces. A sound setup has four properties:
- It checks from more than one location, so a network problem near one checker is not booked as your downtime.
- It checks more often than the outages you care about last: the worst-case detection time equals the check interval.
- It checks what users need, such as a page with a content assertion or the API your app calls, not only a /health route.
- It keeps history long enough to report on the period your target covers.
An uptime monitoring service does this continuously and alerts you when a failure is confirmed; the guide "What is uptime monitoring?" (sutramx.com/guides/what-is-uptime-monitoring) explains how. To test a website's uptime right now, the free website uptime checker at sutramx.com/tools/multi-region-http-check requests a URL from each SutramX probe region at once.
The Free plan checks 50 monitors every 3 minutes, with no card and no expiry. Daily uptime history is kept for 90 days on Free, 12 months on Starter and 24 months on Growth and Pro.
Uptime FAQ
What does uptime mean?
Uptime means the time a system is running and usable. For a website it is the share of time visitors can load it and get a correct response, usually given as a percentage of a month or a year. On a single server, uptime can also mean the time since its last restart.
What is a good uptime percentage?
For most business websites and SaaS products, 99.9% per month is a sensible target. Internal tools can live with 99% to 99.5%. Payments, login and shared infrastructure usually aim for 99.95% or higher, which needs automated failover.
Is 99.9% uptime good?
Yes, for most websites. It allows 43 minutes 12 seconds of downtime in a 30-day month, or 8 hours 45 minutes 36 seconds in a year. It is too loose for systems where every minute costs real money, and stricter than most internal tools need.
How do I check a website's uptime?
For a one-off test, request the site from several locations and compare the results. For an uptime percentage you need continuous checks over time, from outside your infrastructure, which is what an uptime monitor records.