An availability target of 99.9% and one of 99.99% can imply substantially different engineering work. Converting them into permitted unavailability helps Product and Engineering discuss whether the extra investment fits the journeys the service supports.
The calculation needs a definition and a measurement window. A time-based measure counts the share of time a service meets its agreed conditions. A request-based measure counts successful requests out of eligible requests. The downtime equivalents below use a time-based measure over a 365-day year; they do not predict when an outage will occur.
What the extra nines represent
At 99% availability, the annual allowance is about 3.65 days. At 99.9%, it is 8.76 hours; at 99.99%, about 52.6 minutes; at 99.999%, about 5.3 minutes. These are commonly called two, three, four and five nines respectively. The formula is the measurement period multiplied by the unavailable proportion.
The window matters. An annual percentage can hide a concentrated interruption during a busy period, and a monthly objective has a different allowance. A reporting tool unavailable overnight and a checkout unavailable during a promotion can have very different consequences despite the same downtime.
Defining availability around a user journey
A server responding does not necessarily mean a customer can complete payment. The team needs to define what counts as a successful interaction, which requests are eligible and whether timeouts or responses that arrive too late count as failures. The metric should reflect the capability the product promises.
External dependencies also affect the result. A checkout may rely on an identity service and a payment provider as well as the application itself. Their failures can interrupt the journey even when the application’s own infrastructure remains healthy.
Agree how partial failures will be counted. A problem confined to one payment method may leave most requests successful while making the product unusable for a smaller customer group. Segmentation and support reports help assess effects that an overall percentage may conceal.
Comparing the cost of three and four nines
In a hypothetical checkout, moving from three to four nines reduces the annual time allowance from about 8.76 hours to 52.6 minutes. Achieving that target may require redundancy, failover, better detection and more operational work. Those mechanisms also introduce implementation and maintenance costs.
The decision depends on the expected customer and business consequences. Assess whether customers can retry, whether transactions are lost, whether a workaround exists and whether contractual commitments apply. A less frequently used reporting function may justify a different target from a payment journey.
An availability objective is an operating target, not a guarantee that outages will stay within a convenient schedule. The release process and incident response need to account for the remaining risk, including failures that last longer than planned.
Recording the agreement
Document the user journey, success criteria, measurement window and target together. Add the response to a breach: who investigates, how customers are informed and whether reliability work takes priority over further releases. This makes the target usable when the team has to choose its next action.
Google’s guide to service-level objectives explains the relationship between indicators, objectives and agreements, including the need to define the measurement clearly.
