Uptime

"Is the service stable?" went unanswered by anything but instinct for a long time. Neither the asker nor the answerer had a yardstick, so stable meant something different to each person in the room.

Without a yardstick there's no comparison either. A month with six five-minute outages and a month with one thirty-minute outage — there was no way to say which was worse. The total downtime is identical while the experience is not, and no unit existed for discussing the difference.

It surfaced sharply when Sofia took the question in an enterprise security review. Asked how stable the last year had been, the only available answer was "no major outages," and the customer couldn't put that sentence in a contract.

Uptime exists to answer that question with one number. The definition is simple, but measuring it forces you to define what counts as working first, so producing the number ends up being the work of setting the team's standards. Two teams reporting the same figure may be measuring quite different things.

Divide the time the service worked by the total time and multiply by 100. The arithmetic is one line; three decisions come before it.

1. Define working. Does a response arriving at all count, or does a three-second response still count? In practice teams treat the moment request success rate falls below 99 percent as the start of an outage.
2. Decide where to measure. Measured inside the server, network problems go undetected, so an external check sending a real request every minute runs alongside it.
3. Decide the period. A month, a quarter, or a trailing thirty days. Change the period and the same outage becomes a different number, which is why the period belongs next to the figure whenever it is quoted.

Thirty days is 43,200 minutes. With 22 of them down, 43,178 divided by 43,200 gives 99.949 percent for that month.

Convention describes this figure by how many nines it carries. Here is what each allows per month.

1. 99 percent — 7 hours 12 minutes, close to a full working day.
2. 99.9 percent — 43 minutes. Where a typical paid service sets its target.
3. 99.95 percent — 21 minutes.
4. 99.99 percent — 4 minutes 20 seconds. One botched deploy consumes the month's allowance.
5. 99.999 percent — 26 seconds. Unreachable by humans noticing and intervening, so automatic failover is required rather than optional.

How to count partial outages needs deciding too. Whether thirty minutes where saving works and search doesn't counts as downtime changes the figure substantially. Instead of counting hours as on or off, counting the share of successful requests means that if search is 8 percent of requests, those thirty minutes cost 8 percent of them.

The figure alone says nothing about good or bad. What matters is what stops when the service stops. An internal meeting-room booking tool down seven hours a month is an annoyance; payment processing down seven hours is an incident. The same percentage carries a different price depending on what sits behind it.

Setting the target usually goes in this order.

1. Write down the loss from being down. How much revenue an hour of payment downtime costs and how many tickets arrive, as numbers.
2. Weigh the cost of one more nine. Going from 43 minutes to 4 means servers in several regions, zero-downtime deploys, and a rotation covering all hours, so the cost multiplies.
3. Record where those two meet as the SLO. An SLO is the quality target a team commits to.
4. Promise customers something lower than that. Hold the internal target at 99.95 and write 99.9 into the SLA. Without that margin, exceeding the target once is a contract breach.

Averages carry a trap. Staying within 43 minutes for the month means little if those 43 minutes landed at Monday morning start of business. So the number of affected users gets recorded alongside it, and some teams weight downtime by the hour of day it occurred.

Not targeting 100 percent is part of the standard as well. Aim for perfection and halting deploys becomes the safest available choice. So the margin between the target and 100 percent is designated an error budget, and deploys continue while it lasts.

"Last month came in at 99.94 percent. We cleared the SLA threshold."

A report that the promised level held for the period.

"Uptime says 99.9 and responses were taking four seconds. That isn't different from being down."

Having been switched on doesn't describe the experience.

"It was the payment processor's outage and it still lands in our uptime."

Downtime at an external dependency counts against this number.

Pagedeck measures two separate figures: the core actions of opening and saving documents, and everything else like search and templates. Theo measured one figure at first, but a month where search was down thirty minutes came out identical to a month where saving was.

What Grace wanted was a number for the contract. The worst of the previous six months was 99.91 percent, so the internal target went to 99.95 and the contract said 99.9. Without that margin, one bad month triggers the refund clause, and the promise costs more than it wins.

The most common reading is that high uptime means a good experience. Not having stopped sounds like having worked well. But this figure only sees on and off. A state where responses take four seconds and one save in three fails still registers as up, because requests are coming back. In such a month uptime reads 99.95 percent while support volume runs triple, and the figure reported upward looks like a good month. Response time and success rate have to be measured separately alongside it, and those are SLIs.

Treating only your own code as your responsibility is also frequent. When the payment processor fails, nothing in your code is wrong, which feels unfair. But to the user payment is broken, and enterprise contracts are written against whether your service works. So features with external dependencies get a decided plan for when that dependency fails. A route that switches to another provider, or at minimum tells the user and lets them retry later, shortens what counts as downtime. The dependency stays out of your control; how long its failure lasts for your users does not.