Nobody Has 100% Uptime

Sit in enough planning meetings and you will hear it. We cannot afford downtime. The application has to be available all the time. No maintenance windows, no interruptions, nothing.

I have never once heard anyone follow that sentence with a number.

That is the whole problem. Availability is a number, it has a price, and the price roughly multiplies every time you add a nine. Until someone in the room says what a minute of downtime actually costs, the conversation is just people saying the word "always" at each other.

Start with the arithmetic

Target	Downtime per year	Per month
99%	3.65 days	7.2 hours
99.9%	8.8 hours	43 minutes
99.99%	52 minutes	4.4 minutes
99.999%	5.3 minutes	26 seconds

Look at the bottom row for a second.

Five nines gives you five minutes for the entire year. Your monitoring takes thirty seconds to notice something. Your alerting takes a minute to page someone. That person wakes up, finds a laptop, reads the alert, works out which system is unhappy. You have spent your annual budget on one incident, and you have not fixed anything yet.

Five nines does not mean a very good on call rota. It means no human is involved in recovery at all. Everything detects and heals itself, every time. That is a different engineering programme, not an ambitious version of the one you are running.

You cannot be better than the things you sit on

Availability multiplies down the chain. Five components in a row, each at 99.9%, gives you 99.5% between them. That is about forty four hours a year, from parts that all individually looked fine.

Then check what your platform actually promises you. Most cloud providers offer around 99.9% for a single instance and 99.99% across availability zones. Very few things come with five nines attached. If the layer underneath you will not commit to it, you cannot honestly commit to it either.

And SLAs are not promises, they are refund policies. Breach a 99.99% SLA and the customer typically gets ten or twenty percent off that month's bill. That is nowhere near what an outage costs them, and everybody in the room knows it.

What people usually mean

Here is the useful bit. When someone says "we cannot have downtime", they almost always mean one of two things, and they are very different asks.

The first is no unplanned outages. Nothing breaking unexpectedly, no incidents, no getting paged.

The second is no maintenance windows. Nothing scheduled, nothing announced, no Sunday night work.

Most contracts already exclude planned maintenance, so the second one usually has nothing to do with your SLA. What it actually costs you is coordination. Change approvals, customer notifications, weekend staffing, and the negotiation to find a window that works across three regions. That is real money, it is just never on anyone's slide.

That is a perfectly good reason to invest. Just say that is the reason, instead of dressing it up as an availability requirement. You will lose that argument the moment someone checks the SLA.

The reasons that actually hold up

Your customers are everywhere. If people use the product in every timezone, there is no quiet hour. This is the most honest driver, and it is binary. Either you have that problem or you do not.

Security patching. This one gets overlooked and it is the one I would lead with. If you can only patch during a quarterly window, then your exposure to a critical vulnerability is measured in quarters. Being able to patch whenever you like is a security improvement, not a convenience.

Big releases are dangerous releases. Windows are scarce, so changes get batched up to fit them. Bigger batches fail more often and take far longer to unpick when they do. Then everyone gets nervous and batches harder. Teams that can deploy whenever they want end up shipping smaller changes more often, and breaking things less, which sounds backwards until you have lived it.

Rollback becomes real. If you can roll forward without an outage, you can usually roll back without one. Your recovery time drops, which quietly improves your unplanned availability too.

What it costs, and where it turns ugly

This is not a feature you add. It is a constraint you sign up to permanently, and it shows up in every piece of work afterwards.

The database is where people underestimate it badly. Once two versions of your code have to run against the same schema, you cannot just alter a table any more. You add the new column, write to both, backfill the old rows, move the reads across, and only then drop the old one. A change that used to be one release becomes three or four, spread over weeks. Forever. For every schema change.

You also have to run the old version and the new version side by side, against the same data, every time you deploy. The compatibility matrix doubles and you inherit a category of bug that only exists during the rollout and disappears once it finishes, which is a horrible thing to debug.

Then there is testing. You are no longer testing that the new version works, you are testing that the journey from old to new works. Mixed version testing is awkward to automate and it is the first thing that quietly gets skipped when a deadline appears.

And the orchestration doing all this is software too. It has bugs. Plenty of outages are caused by the thing performing the upgrade rather than the thing being upgraded. A complicated rolling upgrade can genuinely give you worse availability than a boring twenty minute window that the team has done fifty times.

There is a ladder, and most teams should get off halfway

The mistake is treating this as a switch. It is not. There are rungs, and the cheap ones near the bottom remove most of the pain.

Going from a four hour window to a twenty minute one removes most of the misery for a fraction of the cost. Being able to abort halfway through and end up back where you started is worth more than never stopping at all. Serving reads while you upgrade covers a surprising number of customers, because plenty of people only need to look at something.

Rung five is where the shape of the work changes. That is the point where your database starts dictating your release plan, and you should be very sure before you step onto it.

What mature products actually do

If you want to know whether anyone truly pulls this off, look at how well engineered software handles upgrading itself.

PostgreSQL is a good place to start, because it has had thirty years of careful work from people who care enormously about not losing your data. A minor version upgrade is a new binary and a restart, so you are down for a few seconds and nobody notices. A major version upgrade is a completely different conversation. You either take a real outage while the data is converted in place, or you stand up a second instance, replicate into it, let it catch up, and cut across once it is current.

Sit with that for a second. A project with that much engineering behind it looked at fully online major upgrades, saw the price, and concluded that the sensible answer was a documented way to build a new one alongside and move over. That is the top of the ladder, and even there it is not free. You are paying for a second copy of your database, a replication setup, and a switchover you had better have rehearsed.

Managed database services make the economics even more obvious, because they put a price on it. Patch a single instance and it goes away for a few minutes. Run a standby in another zone and the same patch becomes a failover measured in seconds, for roughly double the infrastructure bill. Move up to a blue green deployment and the cutover shrinks again, with more machinery underneath it and more cost attached.

Three different amounts of downtime for exactly the same patch, each tier costing more than the one below. That is not a vendor being inconsistent. That is what buying a nine looks like on an invoice.

The number nobody wants to work out

Before approving any of this, make someone produce a figure for what an hour of downtime costs. Lost revenue, service credits, support load, the customers who quietly leave.

Then do the division. If an hour costs five hundred pounds, and the investment removes four hours of planned downtime a year, you are spending to save two thousand pounds a year. If that programme costs a year of engineering time, the payback is somewhere around never.

If an hour costs two hundred thousand, the conversation is completely different and you should have started it sooner.

Same question, opposite answers, and you cannot tell which one you are in without the number.

One more thing about chasing perfection

A target of 100% quietly removes the idea of an error budget. If you are at 100%, you are spending too much on reliability and not enough on everything else. A team running to 99.9% has forty three minutes a month to spend deliberately, on shipping faster or trying something riskier. If you hit 100% for a full year, your target was wrong.

It also creates pressure to reclassify incidents so the number stays clean, which rots an engineering culture faster than almost anything else I can think of.

What to ask in the meeting

• What does one hour of downtime cost us? Nothing useful happens until someone answers this.
• Do you mean no unplanned outages, or no maintenance windows? They are different projects.
• What is our SLA today, and are we actually failing it?
• Our platform commits to 99.99%. Do you want us to promise customers more than our own infrastructure promises us?
• Which is worse for you, twenty minutes on a Sunday, or every feature arriving two weeks later?

Zero downtime upgrades are usually worth it for release speed and patch latency, not for the availability figure. That is a good reason. It is just not the reason people give.

And if nobody can tell you what an hour of downtime costs, you are not ready to sign off the work.