What is a good uptime percentage? 99.9% vs 99.99% explained

A useful uptime target is measurable, relevant to users and realistic for the team operating the service. 99.9% is a common starting point, but the right target depends on the consequences and duration of an outage.

The short answer

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. The main points are:

• 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 measures, what each nine represents in real minutes, and how to pick the target that fits what you run.

What an uptime percentage 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 denominator matters. A month is roughly 43,200 minutes, so a single bad afternoon barely dents the percentage. 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 significant incidents, 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:

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?

Choose by impact: what 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:

A useful gut-check: write down the literal consequence of being down for five minutes. If the 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.

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 consistently.

100% uptime isn't a target. More often it's a sign you stopped measuring consistently.

How to improve uptime against 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

Choose a target that reflects user impact, define the measurement window and treat the remaining percentage as an error budget. Google's SRE guidance on implementing SLOs provides a detailed framework for setting and reviewing the target.