In a renewal meeting someone writes "99.9% availability" into the contract, everybody nods and the group moves on to the next item. Nobody does the division out loud. We'll do it here, because the result is uncomfortable: that number allows your company to be down for eight and three quarter hours a year while the provider goes on meeting the contract to the letter.
A year has 8,760 hours. The rest is primary-school arithmetic that almost nobody bothers to do in front of the customer, and that is worth having in your head before you negotiate anything:
| Availability | Allowed downtime per year | In plain words |
|---|---|---|
| 99% | 87,6 h | More than two working weeks in the dark |
| 99,9% | 8,76 h | A whole working day, plus forty-five minutes |
| 99,99% | 52,56 min | One long meeting, in a whole year |
| 99,999% | 5,26 min | Less than it takes a server to boot |
Look at the jump between the first two rows. From 99% to 99.9% there is one decimal place on paper and 78.84 fewer hours of downtime in reality. That is why each extra nine costs so much: it is not bought with luck or with a better server, it is bought with architecture. And it is also why 99.9% is scattered across so many contracts: it is the number that sounds serious and can still be promised without changing anything.
The same number, two promises that are not the same deal
This is the part that actually decides what you signed, and it fits in one line of the contract that usually sits three pages past the percentage: the measurement period.
A 99.9% measured annually gives you a budget of 8.76 hours to spend across twelve months. You can burn the lot on the second Tuesday of March, in one go, and still close the year in compliance. A 99.9% measured monthly is calculated over the 730 hours of an average month: that is 43.8 minutes, and what you do not spend in January is not banked for February. Mind the counting trap: the total allowed across the year is the same, 8.76 hours either way (43.8 minutes × 12 is exactly those 8.76 hours). What changes is that monthly measurement forbids you from bunching it: the ceiling on a single outage drops from 8.76 hours to 43.8 minutes. Same headline, same figure, twelve times less room to pile it all into one bad day. If the contract does not say over what period it is measured, you have not agreed a service level: you have agreed an adjective.
What the percentage cannot tell you
We have spent years arguing over contracts with this arithmetic in hand for one specific reason: an annual availability percentage carries no information at all about how long a single outage lasts. Thirty-five fifteen-minute outages spread across the year add up to 8.75 hours and scrape past 99.9%. One single Tuesday down from nine to six is nine hours: it misses that same 99.9% by fourteen minutes. Almost the same total, and the contract treats them the opposite way round from how your company does.
Fifteen minutes is an annoyance: people get up for a coffee, come back and carry on. Nine to six is a different animal — the warehouse ships nothing, the sales team stares at a frozen screen, the phone starts ringing upstairs and somebody has to call a customer to explain why their delivery is not going out today. What your business feels is not the annual total: it is the longest single outage of the year. And that number, the only one that matters, does not appear in the contract.
Warning: Undefined variable $slugRto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 236
Warning: Undefined variable $tituloRto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 236
Warning: Undefined variable $slugRto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 237
Warning: Undefined variable $tituloRto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 237
Warning: Undefined variable $slugRto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 238
Warning: Undefined variable $tituloRto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 238
That number has a technical name and it is the RTO, the recovery time objective — we gave it a whole post, . It is not the same thing as availability and it is negotiated separately, but it is what you were trying to buy when you wrote three nines into the minutes.
Before the division, check what counts
The 8.76 hours above are the theoretical ceiling. The real one depends on two clauses that are always there and almost never read.
The first is planned maintenance. In every contract in this industry we have read, windows announced in advance do not count as unavailability. It is a reasonable convention — things have to be patched, and the provider that never stops is the one that never updates — but it changes the arithmetic: a 99.9% annual figure can coexist with a planned six-hour window on a Saturday without breaking a sweat. If your business trades on Saturdays, you have just given away six hours you thought you had. What to look at is not whether the exclusion exists, but how many windows a year the contract allows and with how much notice.
The second is what happens if it is breached. The usual penalty is a credit against the period's fee: you get back a slice of what you pay. You never get back what you lost, and you should not expect to — hardly any provider signs an open-ended clause against your P&L, and the ones that do tend to cap it somewhere else. That said, it is worth doing the subtraction and seeing it written down: if your monthly invoice is €1,200 and the maximum credit is 10%, the most expensive possible breach compensates you with €120. That Tuesday costs considerably more. An SLA is not insurance; it is a quality metric with a token fine behind it. Treating it as insurance is the expensive mistake.
The nines do not depend on luck, nor on the hardware
When someone wants to go from 99.9% to 99.99% they almost always open the hardware catalogue. That is the wrong place to look. The reference study on why large services fail — Oppenheimer, Ganapathi and Patterson, presented at USENIX in 2003, whose diagnosis we still run into in the field twenty-three years later — found that operator error was the single largest cause of outages in two of the three services analysed, and that more than half of those errors — in one of the services, close to 100% — were configuration errors, made while somebody was changing something in the system. Not a broken disk: a person touching production.
Warning: Undefined variable $slugPruebas in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 270
Warning: Undefined variable $tituloPruebas in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 270
Warning: Undefined variable $slugHa in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 270
Warning: Undefined variable $tituloHa in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 270
Warning: Undefined variable $slugPruebas in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 271
Warning: Undefined variable $tituloPruebas in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 271
Warning: Undefined variable $slugHa in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 271
Warning: Undefined variable $tituloHa in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 271
Warning: Undefined variable $slugPruebas in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 272
Warning: Undefined variable $tituloPruebas in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 272
Warning: Undefined variable $slugHa in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 272
Warning: Undefined variable $tituloHa in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 272
The practical consequence is unglamorous: the nine you are missing comes from governing change, not from buying a more expensive array. A staging environment, phased rollouts, a rehearsed way back, and somebody reviewing before production gets touched on a Friday. We pulled another thread out of that same study earlier this week, the one about testing against the live system — we wrote it up in . And on the design side it is worth being clear about something we have written before: , which is exactly what this post is about.
Warning: Undefined variable $slugRepuesto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 276
Warning: Undefined variable $tituloRepuesto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 276
Warning: Undefined variable $slugRepuesto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 277
Warning: Undefined variable $tituloRepuesto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 277
Warning: Undefined variable $slugRepuesto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 278
Warning: Undefined variable $tituloRepuesto in /var/www/html/public/blog/el-99-9-no-te-dice-cuanto-dura-la-caida.php on line 278
The rest of the work is the usual work, and it is the axis we measure any design against: failure is inevitable, an outage is a design decision. A disk is going to die, a node is going to reboot on its own, a large provider is going to have a bad day. With your data on a single disk, failure and outage are the same event. With your data replicated across three separate machines, that same dead disk is maintenance paperwork and nobody in the office notices. Identical breakage, opposite outcome — and in between there is no luck, there are decisions somebody made months earlier. That includes the boring ones: we already wrote about how , which is the crack that turns paper redundancy into a genuinely long outage.
The three questions, and our own conflict of interest
Before the questions, cards on the table: we sign service level agreements too, and this post pushes the conversation exactly towards what we sell — architecture, recovery, on-call. Keep that in mind as you read it, and put these three questions to any provider, us included:
- Over what period is that percentage measured? Annual and monthly are the same number and two different promises: the monthly one stops you bunching the outage into a single day. If the answer takes a while, you already know nobody had looked at it.
- What is the longest outage we accept, and what in the design holds that up? This is the real question, and it is answered with architecture (replicas, spreading across rooms, machine-by-machine updates), not with a percentage. If the answer is a percentage, ask again.
- What falls outside the count, and how much do they pay you if it is breached? How many maintenance windows a year, with how much notice, and the maximum credit in euros — not as a percentage. Seeing it in euros changes the conversation.
A warning about the second question, for the sake of honesty: anyone who answers with a round number of minutes and a confident face is selling you something. We have one full-recovery drill clocked at fourteen minutes, and even so we do not use it as a contractual promise, because a time measured in one specific drill is not a guarantee for the next incident. The honest move is to show the design and explain what breaks at each step, not to show a pretty number.
If you take only one thing out of that meeting, make it this one: the percentage is the summary, not the agreement. Ask about the width of the gap.
Sources and method: the downtime hours are straight arithmetic over a 365-day year (8,760 h) and an average month of 730 h; the reader can redo them in ten seconds and we recommend doing exactly that. The figure on causes of failure comes from D. Oppenheimer, A. Ganapathi and D. A. Patterson, "Why Do Internet Services Fail, and What Can Be Done About It?", 4th USENIX Symposium on Internet Technologies and Systems (USITS), 2003 — usenix.org. That study measures three specific services over three to seven months (501 component failures, 117 service outages); in the third service it was network problems that dominated, not the operator, and its own authors warn the sample may be biased. We cite it for the direction it points in, not as a universal statistic. The planned-maintenance and service-credit clauses we describe are industry practice observed in real contracts we have read, not a quotation from any particular provider: check the ones in yours, which is what they are written for. The €1,200 example is illustrative, and the fourteen minutes are one timed drill of our own, never a contractual guarantee.
How long was your longest outage last year?
If you do not have the figure, that is the first finding. We do infrastructure consulting without selling anyone's licences — which is why we can tell you that you do not need another nine — and we build recovery plans with the RTO written down and rehearsed, not promised.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN