Reliability Target
A reliability target is the availability, latency, or durability a service promises over a window, chosen from user needs and cost rather than aspiration.
Definition
A reliability target is a measurable goal for how reliably a service must behave over a defined period, expressed through indicators such as availability, latency, or durability.
Context and scope
Set during service design and reviewed quarterly, it guides architecture, testing depth, and the trade-off between reliability and release velocity.
Common misconceptions
- One hundred percent reliability is the right target
- A target guarantees that every individual request succeeds
- Targets should be set by infrastructure teams alone
Anti-patterns
- Choosing a target because a competitor advertises one
- Setting a target with no matching measurement or owner
- Raising the target without funding the work required to reach it
Related concepts
Authoritative source
What a target is
A reliability target states how reliable a service must be, over a period, on a defined measure. “Ninety-nine point nine percent of checkout requests succeed over thirty days” is a target. “The site should be reliable” is not. Targets turn reliability into something engineers can design for, test against, and report on. They also expose the cost curve: each additional nine typically multiplies the engineering effort and reduces the pace of change.
Choosing the number
Start from user expectations and business impact, not from an industry default. How long can checkout be unavailable before customers leave? What does an hour of downtime cost? What do support tickets and contractual terms imply? Segment by journey: a search page and a payment path rarely deserve the same target. Compare the cost of downtime with the cost of redundancy, testing, and slower releases. The right target is the point where further reliability spending buys less than the failure it prevents.
Measuring it
Define the indicator precisely: which requests count, which count as good, and over what window. Exclude maintenance only if users are truly unaffected. Measure from the user’s side where possible, because server-side success can still mean a broken page. Publish the result alongside the target and review misses with the same rigor as incidents.
Trade-offs
Targets constrain velocity. A service promising four nines cannot deploy risky changes without progressive delivery, extensive testing, and fast rollback. Compared to an aspirational goal, a target implies budget: error budgets, resilience reserves, and on-call capacity. If the organization is unwilling to fund those, the target is a slogan.
Review
Revisit targets when usage, architecture, or contracts change. For example, a service that moves from internal use to paid customers may need a stricter target and a different measurement window. Document the rationale so future teams understand why the number exists.