“Good” uptime isn't the biggest number you can quote — it's the one you can measure, defend and actually keep. For most sites that number is 99.9%. Whether you should aim higher comes down to a single question: what breaks, and for whom, when you're down?
The short version
- For most websites a good uptime percentage is 99.9% — about 44 minutes of downtime a month.
- Uptime is just
time up ÷ total time. The window is large, so a few minutes of downtime visibly moves the figure. - Each extra “nine” cuts allowed downtime roughly 10×: 99.9% → 99.99% goes from ~44 minutes a month to ~4.
- The right target depends on what breaks when you're down — match it to impact, not vanity.
- 100% is a trap. Pick a realistic target, treat the gap as a budget, and measure it honestly.
The short answer
Definition
A good uptime percentage is for most websites 99.9% — roughly 44 minutes of downtime a month. Revenue-critical services aim higher (99.95%–99.99%); a personal blog can happily sit at 99%. The right number is the one you can measure and defend, not the most impressive one you can put on a slide.
Most people land on this question because a tool, a host or an SLA quoted them a figure and they want to know whether it's any good. Here's the honest version, before the detail:
- 99% — fine for a hobby project. It's also three and a half days of downtime a year, so not for anything that matters.
- 99.9% — the sensible default for a small business site. About 44 minutes a month: enough room for the occasional bad deploy, tight enough that real outages stand out.
- 99.95%–99.99% — for things that earn money while you sleep: stores, SaaS apps, public APIs.
- 99.999% — “five nines”, for infrastructure other companies build on. Expensive, and rarely worth chasing otherwise.
The rest of this article is the why — what the percentage actually measures, what each nine costs you in real minutes, and how to pick the target that fits what you run.
What an uptime percentage actually means
Uptime is the share of a period that your service was available. It isn't a rating or a grade — it's a plain ratio of time, which is exactly why those decimal places matter so much.
the formula
worked example · 30-day month
43,200 min total · 43 min down
(43,200 − 43) ÷ 43,200 × 100 = 99.90%
The denominator is the catch. A month is roughly 43,200 minutes, so a single bad afternoon barely dents the percentage — and, going the other way, a number that looks excellent can still hide a surprising amount of downtime. A site that's down for nine minutes every single day still reports a respectable-sounding 99.4%. You can't eyeball it; you have to measure it.
The “nines” of availability
Percentages this close to 100 are hard to feel, so the industry counts nines instead. 99% is “two nines”, 99.9% is “three nines”, 99.99% is “four nines”, and so on. Each nine you add cuts your allowed downtime by roughly an order of magnitude — which is much easier to grasp as actual time:
That right-hand column is the number to internalise. It's your downtime allowance — the budget you have to spend on deploys, maintenance and the occasional genuinely bad day — not a promise the universe makes to you. Two things eat into it: how often you go down (reliability) and how long you stay down (time to detect plus time to fix).
99.9% vs 99.99%: the difference is bigger than it looks
On paper these two are almost the same — one decimal place, a rounding error apart. In practice they describe very different operations:
Downtime / month
43m 50s
8h 46m a year
Downtime / month
4m 23s
52m 36s a year
Forty-four minutes a month versus four. And here's the part the numbers don't show: the extra nine almost never costs 10× more effort — it costs more like 10–100×. Going from 99.9% to 99.99% generally means removing single points of failure: redundant servers, more than one region, automated failover, and the operational maturity to deploy in the middle of the day without anyone noticing. That's an organisational investment, not a setting you flip.
So what's a good target for you?
Pick by blast radius — what actually happens, and to whom, in the first five minutes of an outage. Map your service to the closest row and you'll have a target you can defend in a meeting:
Personal site or blog
A few hours a year won't hurt anyone.
Small business website
The sensible default for most teams.
SaaS app or online store
Customers feel the minutes — and remember them.
Payments or a public API
Other people's money flows through it.
Infrastructure others build on
Rarely worth chasing below this tier.
A useful gut-check: write down the literal consequence of being down for five minutes. If the honest answer is “a handful of people see a maintenance page,” then 99.9% is plenty and chasing more is a waste of good engineering time. If it's “we lose real revenue every minute and start trending for the wrong reasons,” buy the extra nines.
Whatever you pick, the target is only real if you're measuring against it. Every 247Monitor plan — including the free one — tracks your actual uptime over time; the faster check intervals on paid plans simply narrow the window between “down” and “you know,” which is the part of downtime you have the most control over. See how intervals map to plans on the pricing page.
Why 100% is the wrong goal
It's tempting to aim for a perfect score, but 100% is a promise you'll break and a goal that quietly punishes good practice. Deploys, dependency wobbles, DNS changes, certificate renewals and the occasional cloud-provider hiccup mean perfection simply isn't on the menu — and a target of 100% gives you nowhere to put the planned, sensible downtime that healthy systems need.
The fix is an idea borrowed from site-reliability engineering: the error budget. A 99.9% target is explicit permission to be unavailable for about 44 minutes a month. That's a budget — for deploys, maintenance windows, migrations and the odd bad day — and the point is to spend it deliberately.
downtime budget · target 99.9% · this month
on trackSpent
16m 04s
Remaining
27m 46s
Reframing the gap as a budget changes the conversation. Burning through it early in the month is a signal to slow down and stabilise. Barely touching it, month after month, can mean the opposite — that you're over-investing in reliability you could be spending on shipping. Either way, you only get the signal if you're tracking the number honestly.
100% uptime isn't a target. More often it's a sign you stopped measuring honestly.
How to actually hit your target
A target you don't measure is a wish. Holding a real number — and being able to prove it — comes down to a handful of habits:
- Measure from outside, around the clock. Internal dashboards miss the failures that hurt most — DNS, expired certificates, a whole region dropping off the map.
- Check from several regions and confirm failures. A single vantage point inflates your downtime with false positives; requiring a second region to agree is the biggest single defence against phantom outages.
- Kill the avoidable outages early. SSL and domain expiry checks, and the silent background job that stopped a week ago, are the most preventable minutes you'll ever lose.
- Shrink time-to-know. A big slice of most downtime is simply “we hadn't noticed yet.” Faster check intervals attack that part directly.
- Review the trend, not just the live light. Response time usually creeps up well before a site falls over — the early warning is in the graph, not the status dot.
If you're starting from scratch, our step-by-step guide to monitoring website uptime walks through the whole setup, and what is uptime monitoring? covers the fundamentals.
Uptime vs SLO vs SLA — three words people muddle
These get used as if they're the same thing. They're not, and the distinction matters the moment money or contracts are involved:
Uptime is the measurement
The actual percentage your monitoring recorded over a window. Past tense, observed, not negotiable — 99.94% last month is 99.94% last month.
An SLO is your target
A service-level objective is the number you're aiming for — 99.9%, say. It's internal, it's a goal, and the downtime budget above is simply the room an SLO gives you.
An SLA is a promise
A service-level agreement is a contractual commitment to a number, usually with a refund or service credit if you miss it. Crucially, an SLA from your host is a refund policy, not a smoke alarm — it might pay you a small credit after the fact, but it won't wake you up, and it only covers their slice of the stack. Monitoring is what tells you in time to do something about it.
Frequently asked questions
Is 99.9% uptime good?
For most websites, yes. 99.9% (“three nines”) allows about 43 minutes and 50 seconds of downtime a month, or roughly 8 hours 46 minutes a year. It's the honest baseline for a small business site. Services that lose money by the minute — checkout, payments, a public API — usually aim for 99.95% or 99.99% instead.
What does 99.99% uptime mean in real downtime?
99.99% (“four nines”) permits about 4 minutes 23 seconds of downtime per month, or roughly 52 minutes a year. It's ten times stricter than 99.9%, and reaching it reliably usually means redundant infrastructure, multiple regions and automated failover — a real engineering investment.
What's the difference between 99.9% and 99.99%?
One decimal place, but a 10× difference in allowed downtime: about 44 minutes a month versus about 4. Each extra “nine” cuts the downtime budget by roughly an order of magnitude — and tends to cost far more than 10× the effort to achieve, because it forces you to remove single points of failure.
Is 100% uptime possible?
Not realistically, and you shouldn't promise it. Deploys, dependencies, DNS, certificates and the occasional cloud-provider wobble all conspire against perfection. A perfect score over a long enough window usually means you've stopped measuring honestly rather than that nothing ever broke.
How is uptime percentage calculated?
Uptime % = (total time − downtime) ÷ total time × 100, measured over a window such as a month. For a 30-day month (43,200 minutes), 43 minutes of downtime works out to (43,200 − 43) ÷ 43,200 × 100 = 99.90%. Because the denominator is large, even a few minutes of downtime visibly moves the figure.
What's the difference between uptime, an SLO and an SLA?
Uptime is the number you actually measured. An SLO (service-level objective) is the internal target you're aiming for — say 99.9%. An SLA (service-level agreement) is a contractual promise about that number, usually with a refund or credit if you miss it. You monitor uptime to know whether you're meeting your SLO, and to defend your SLA.
The bottom line: a good uptime percentage is a target you can keep, matched to what actually breaks when you're down. For most sites that's 99.9%; for things that earn money by the minute it's a nine or two more. Pick the number, treat the gap as a budget, and measure it honestly — that last part is the whole job. Start monitoring free →