I build Tallwatch, so people ask me a version of this question constantly: "what uptime should we be aiming for?" And almost everyone who asks has already half-decided the answer is "as many nines as possible." That instinct is wrong, and it's expensive. More nines is not more virtue. Past a point it's a tax you pay on engineering time that your users will never notice and your competitors are spending on shipping.
So let me do two things. First, translate the nines into plain English with the actual downtime math, so "99.9%" stops being a vibe and becomes a number of minutes you can reason about. Then the honest twist this whole blog is built around: the percentage you publish is only as real as the way you measured it, and most teams measure it in a way that makes their number worse than the truth.
The nines, in minutes you can feel
A percentage of uptime is abstract until you convert it into the time your service is allowed to be unreachable. Here is the table I wish more homepages printed:
| Target | Nickname | Downtime / year | Downtime / month |
|---|---|---|---|
| 99% | "two nines" | ~3.65 days | ~7.3 hours |
| 99.9% | "three nines" | ~8.77 hours | ~43.8 minutes |
| 99.99% | "four nines" | ~52.6 minutes | ~4.38 minutes |
| 99.999% | "five nines" | ~5.26 minutes | ~26 seconds |
Read that column on the right slowly, because it reframes the whole conversation. The difference between three nines and four nines is the difference between being allowed roughly 44 minutes of downtime a month and roughly 4 minutes. The difference between four and five nines is the difference between 4 minutes a month and 26 seconds — a single bad deploy, a single certificate hiccup, a single dependency wobble blows your entire annual budget before lunch.
Each nine you add multiplies the cost of reaching it by roughly ten, because you're now engineering against rarer and rarer failure modes: redundant everything, automated failover that's tested under load, zero-downtime deploys, and a team that can detect and recover inside seconds rather than minutes. That's not a feature you turn on. It's an entire operational posture.
What target is actually right for you
The right target isn't the highest one. It's the lowest one your users genuinely feel, because every nine above that is effort spent on a quality nobody is experiencing.
Side projects and internal tools. 99% to 99.9% is completely honest and completely fine. Nobody is paging an engineer at 3am because a hobby project blipped for ten minutes. Aim for three nines, get alerted when you breach it, and go build the next thing.
Growing SaaS with paying customers. Three nines (99.9%) is the realistic, respectable target, and it's what most mid-market SaaS actually delivers regardless of what the marketing page promises. It gives you ~44 minutes a month of headroom, which is enough to absorb a deploy gone wrong and a recovery without missing the number. Four nines is a stretch goal you earn over time, not a launch promise.
Genuinely critical infrastructure. Payments, healthcare, anything where downtime is measured in lawsuits — four nines and up, with the budget, redundancy, and on-call maturity that requires. If you're in this bucket you already know it, and you're not reading a founder's blog to find out.
The trap I watch small teams fall into is promising five nines because it sounds serious. Five nines is a 26-second-per-month budget. To defend it you need infrastructure most early-stage teams can't justify, and the moment you publish "99.999%" and then have a 20-minute incident — which you will — you've burned more trust than a humble, accurate 99.9% would have cost you in the first place. Pick a target you can actually hold, and beat it quietly.
SLAs: the promised number versus the measured one
Here's where it gets slippery. An SLA is a number you promise, usually with credits attached if you miss it. But there are two completely different numbers in any uptime conversation, and people blur them constantly:
- The number you promise (your SLA).
- The number you measure (what your monitoring actually recorded).
These drift apart for boring, self-serving reasons. The provider gets to define "downtime" — scheduled maintenance doesn't count, partial degradations don't count, the outage clock starts when they acknowledge it, not when you first couldn't load the page. So the 99.99% on the contract and the 99.7% your users lived through can both be "true" depending on who's holding the stopwatch and how they defined the words.
Which is exactly why your own independent measurement matters more than anyone's promise. And that brings me to the part most posts skip.
Your uptime number is only as honest as how you measured it
Here's the thing almost nobody tells you: a single-probe monitor systematically over-reports your downtime. It makes your number look worse than reality, and you might be paying SLA credits or losing sleep over outages that never happened to your users.
A check from one location measures two things at once and reports them as one: is your site up, and is the network path between that one probe and your site healthy. Most of the time those move together. But the moment that single probe hits a congested transit link, a flapping route, or a bad peering hour, it records your site as down — when every real user was loading it fine. Its own network blip becomes a black mark on your uptime number.
So a single-probe monitor doesn't give you a neutral measurement. It gives you your real downtime plus every network hiccup between itself and you, all attributed to you. The more nines you're chasing, the more this matters, because at four nines your entire monthly budget is 4 minutes — and a single false 4-minute "outage" from one flaky probe can erase your whole number for the month.
The fix is to stop trusting one vantage point. Tallwatch checks each target from several regions every minute and only records an outage when at least two regions agree the target is down in the same round. One region having a bad hour doesn't count against your uptime, because the other regions saw your site just fine. The number you get is closer to what your users actually experienced — not what one probe's network was doing.
That's not a marketing distinction. It's the difference between an uptime percentage you can stand behind on a status page and one that's quietly inflated with somebody else's network problems.
Where to land
Pick the lowest target your users actually feel — for most teams that's three nines — and spend the energy you saved on detecting and recovering faster, because how quickly you respond shapes your real number far more than the target you wrote down. (When you're deciding what an outage is worth defending against, it helps to know what an hour of downtime actually costs you.) Then measure honestly: a number built on a single probe is inflated by that probe's network, and a number built on multi-region consensus is closer to the truth. If you want to see how that consensus approach works in practice, here's the short version of what Tallwatch is and isn't.
A good uptime percentage isn't the biggest one you can fit on a slide. It's an accurate one you can defend.