"Four nines" sounds impressive until you ask what it permits. This guide converts uptime percentages into real minutes and seconds, explains how SLAs and SLOs differ, and shows why two honest tools can report different uptime for the same site. By the end you should be able to read any uptime promise critically and set a target that suits your own business.
The arithmetic behind the percentages
Uptime is the share of a period during which the service was available:
uptime % = (total time - downtime) / total time x 100
allowed downtime = total time x (1 - target / 100)The tables below use these period lengths: 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. (A leap year adds 86,400 seconds; a 31-day month allows about 3.3% more than a 30-day one.)
Downtime allowed per period
| Target | Per day | Per week | Per 30-day month | Per year (365 days) |
|---|---|---|---|---|
| 99% | 14 min 24 s | 1 h 40 min 48 s | 7 h 12 min | 3 d 15 h 36 min (87.6 h) |
| 99.5% | 7 min 12 s | 50 min 24 s | 3 h 36 min | 1 d 19 h 48 min (43.8 h) |
| 99.9% | 1 min 26.4 s | 10 min 4.8 s | 43 min 12 s | 8 h 45 min 36 s |
| 99.95% | 43.2 s | 5 min 2.4 s | 21 min 36 s | 4 h 22 min 48 s |
| 99.99% | 8.64 s | 60.48 s | 4 min 19.2 s | 52 min 33.6 s |
| 99.999% | 0.864 s | 6.048 s | 25.92 s | 5 min 15.36 s |
Each extra nine cuts the allowance by a factor of ten. Going from 99.9% to 99.99% does not make a service slightly better; it shrinks the monthly budget from 43 minutes to just over 4.
What the numbers feel like
- 99% allows a whole working morning of downtime every month. Many small sites on basic hosting sit around here without anyone noticing.
- 99.9% ("three nines") allows one decent incident per month if it is resolved within 40 minutes. This is a sensible aspiration for a small business on managed hosting.
- 99.99% allows about four minutes a month. A single manual response (someone notices, logs in, restarts something) can consume the entire month's budget. Reaching it requires redundancy and automated failover, not heroics.
- 99.999% allows under half a minute a month. At that level the monitoring system itself must be more reliable than the thing it measures, and most outages will be shorter than a check interval.
SLA, SLO and SLI: three different things
These terms are often mixed up.
| Term | Meaning | Who sees it | Consequence of missing |
|---|---|---|---|
| SLI (indicator) | The measurement, such as the proportion of successful requests | Engineers | None by itself |
| SLO (objective) | An internal target for the SLI, such as 99.9% monthly | Your team | Triggers reliability work |
| SLA (agreement) | A contractual promise to customers, usually with remedies | Customers and lawyers | Credits, refunds or penalties |
Providers typically set the SLA looser than their internal SLO. If you want to deliver 99.9% to customers, your internal target should be tighter, so that you have a margin before a breach has contractual consequences.
An SLA is also not a prediction. A host advertising 99.95% is promising a service credit if they miss it, not guaranteeing it will not happen. Read the fine print for how credits are claimed, what is excluded and who measures.
The error budget idea
An SLO of 99.9% over 30 days gives you an error budget of 43 minutes 12 seconds. If you have used half of it by the 10th of the month, risky deploys wait. If you have barely touched it, you can ship faster. The budget turns an abstract percentage into a decision tool, and it stops teams from treating any downtime as a disaster or all downtime as acceptable.
Measured versus reported uptime
The figure on a sales page and the figure in your own monitoring can both be honest and still disagree. The differences come from decisions that are rarely stated.
What counts as "down"
- Does a slow response count? A page returning in 20 seconds is technically up.
- Does a 500 error on one API endpoint count when the homepage works?
- Does a 200 response containing an error message count? Only a keyword or content check can tell. Use a keyword-aware uptime monitor for this.
- Does a regional failure count, if only one of several check locations sees it?
Where the measurement is taken
A provider measuring from inside its own network sees none of the problems between that network and your visitors: DNS failures, routing issues, a CDN misconfiguration. An external monitor sees what a user sees. Neither is wrong, but only the external one reflects the visitor experience. The HTTP status checker is a quick way to see what an external client receives right now.
Planned maintenance exclusions
Many SLAs exclude scheduled maintenance, force majeure events and issues caused by the customer. That can legitimately lift reported uptime. Two cautions:
- Visitors cannot tell planned from unplanned downtime. A shop closed during a maintenance window still loses sales.
- Exclusions should be announced in advance and shown separately, not quietly deleted from the report. If you exclude maintenance from your own figures, publish both numbers: uptime including maintenance and uptime excluding it. Serving a proper 503 with
Retry-Afterduring planned work also keeps the record clean; see website maintenance mode done right.
How the average is built
Averaging daily percentages is not the same as dividing total downtime by total time when days differ in length of data, and averaging across multiple monitored URLs can hide a broken one. If a site has ten pages and one is down all month, "average uptime" across them is 90%, while the checkout it was protecting was at 0%. Always state exactly what was measured.
Why the number depends on check frequency
Uptime from a monitor is computed from samples. If checks run every 5 minutes and one fails, the report must assume some amount of downtime for that interval. Tools handle this differently, but the implications are the same:
- A 15-minute interval cannot resolve an outage shorter than 15 minutes. One failed check may be charged as up to 15 minutes of downtime, or a short outage may be missed entirely.
- A 1-minute interval resolves roughly to the minute, so reported downtime is close to real downtime.
- Tools that confirm a failure with a second check before declaring an incident (as SiteDownCheck does) deliberately ignore single isolated failures. That is good for avoiding false alarms, and it means very brief true outages may not appear. This is a reasonable trade, but state it when you quote the figure.
So a site showing "100% uptime" on hourly checks and the same site showing "99.93%" on one-minute checks may be telling the same story with different resolution. When comparing hosts or tools, compare the interval, the failure definition and the location set first. How often should you monitor a website covers choosing the interval.
Choosing a target for your own site
Work backwards from what downtime costs and what you can afford to engineer.
- Estimate your tolerable monthly downtime. For many small sites, 43 minutes (99.9%) is more than adequate; 7 hours (99%) may even be acceptable for a hobby project.
- Check that your stack can reach it. A single server with one database and a human responder will struggle to deliver 99.99%, because the response time alone eats the budget.
- Count dependencies. Your availability cannot exceed the product of the things you depend on in series. If your host is 99.95%, your DNS 99.99% and your payment provider 99.9%, the best the combined chain can give is roughly 99.84% (0.9995 x 0.9999 x 0.999), before your own bugs.
- Pick a target slightly above what you currently achieve, and improve from there.
- Publish it honestly. A public status page with real incident history earns more trust than an unexplained "99.99%" badge. If you do show uptime badges, make sure they come from real measurements.
अगले कदम
- Start measuring from outside with the uptime monitor.
- Show real history on a status page or with uptime badges.
- Learn how to choose intervals in how often should you monitor a website.
- Write up misses with the incident postmortem template.
सामान्य प्रश्न
Is 99.9% uptime good enough?
For most small and medium websites, yes. It allows about 43 minutes of downtime in a 30-day month and 8 hours 45 minutes in a year. If you sell online during narrow time windows, or have customers who depend on your service during business hours, ask whether a single 40 minute outage at the wrong time is survivable.
What is the difference between SLA and SLO?
An SLO is an internal reliability target your team aims for. An SLA is a contract with customers that specifies remedies, such as service credits, if you fall short. SLOs are usually stricter than SLAs so you have a safety margin.
Why does my host report higher uptime than my monitor?
They probably define "down" differently or measure from a different place. A host may measure at its own network edge, exclude maintenance and ignore slow responses, while an external monitor sees DNS, routing and application errors too. Compare definitions, locations and check intervals before drawing conclusions.
Does scheduled maintenance count against uptime?
It depends on the agreement. Many SLAs exclude announced maintenance, but visitors still experience it as downtime. Report both figures if you can, and serve a 503 status during the work so tools and search engines understand it is temporary.
Can a monitor with long intervals show 100% uptime for a flaky site?
Yes. If outages are shorter than the gap between checks, they may never be sampled. A 100% figure from infrequent checks tells you only that those specific samples passed, not that nothing went wrong in between.
Get notified when this guide updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.