Most startups have an unwritten answer to how reliable their product should be, usually “as reliable as possible”, and it lives in the heads of whoever gets woken up. We recommend writing the answer down as a small number of explicit targets, agreed by the people who own the business, and then using those targets to decide when to ship faster and when to stop and fix things.
Targets, indicators and the allowance for failure
An SLI (service level indicator) is a measure of how a service is performing from the user’s side, best expressed as good events divided by total events: successful checkouts out of all checkout attempts, for example. An SLO (service level objective) is a target for that indicator over a time window, such as 99.9% of checkouts succeeding over 30 days. An SLA (service level agreement) is the contract that says what happens, usually a financial penalty, when a target is missed.
The gap between 100% and the target is the error budget, the amount of failure the target allows. A 99.9% target over 30 days, for example, allows 43.2 minutes of downtime in that window. At four nines (99.99%) the allowance falls to under five minutes in 30 days. Many organisations settle around 99.9%, some at 99.95%; we treat 99% as relaxed and 99.99% as demanding.
For speed, our starting rule of thumb is that about 100 milliseconds feels instant to a user, and anything over 1,000 milliseconds feels slow. A latency target is then the share of requests that complete under your chosen threshold, not the threshold on its own.
Why 100% is the wrong target
We treat 100% as almost always the wrong target, for three reasons: the cost of reliability rises steeply as you add nines, extreme reliability slows down feature work, and 100% cannot be reached anyway. While there is budget left, the team can take sensible risks such as faster releases or experiments; when the budget is nearly spent, that is the signal to put time into stability instead.
Your dependencies also limit what you can promise. When a service needs two others to work, their availabilities multiply: dependencies at 80% and 90% leave the service at no more than 72%. When either of two redundant paths will do, the chances of failure multiply instead, so the same pair could reach 98%. Both calculations assume failures are independent, which a shared cloud region outage would break, so treat the result as a ceiling rather than a forecast.
The business decides
Reliability targets are a business decision. We recommend that a group drawn from business, product, engineering and operations agree the targets, with the business owning the final call, because a target decides how engineering time is split between features and stability and what customers can expect. Engineers bring the data and explain the trade-offs; a founder or product owner says how much failure the business can accept.
One shortcut to avoid is copying today’s performance into the target. If checkout succeeded 99.95% of the time last month, writing down 99.95% skips the question the exercise exists to answer: is that good enough, more than you need, or not enough? We only do it when experimenting. A target should also be realistic for where you are: a service running at 99.5% should not be handed a 99.999% goal. The reliability you deliver also becomes what users expect, written down or not.
Start with one service and a handful of targets
You do not need targets for everything. We recommend starting small with one critical service; fewer than five high-level targets are usually enough to capture what users expect from a service. For a first attempt, our default is two or three simple, realistic targets that everyone involved has agreed. Pick the service whose failures your customers notice first, often sign-up, login or checkout, and give it an availability target and a latency target. Review the targets at least once a year, and add more only with good reason.
Measure whole user journeys
A target measured only at the backend can look healthy while users struggle. We recommend building targets around critical user journeys (the end-to-end tasks users care about, such as adding an item to a cart) and checking them with synthetic monitoring (scripted test requests that walk the full path through the product). Google has published a case from its own access proxy, where a single 99.99% target based on a probe to a simple backend missed several outages, because each broken use case was too small to move the overall figure. Once the team defined a journey for each kind of use, each with its own probe, it reports that the targets caught every significant outage from then on.
Per-customer targets for B2B products
If you sell to other businesses (B2B) and a few customers bring in most of your revenue, an average across all customers can hide a total outage for one of them. Take an average burn rate (how fast the error budget is being used) of 10: that could be one customer at 100 and nine at zero. Per-customer targets and alerts let you spot that kind of problem before the customer reports it. We advise covering only critical workloads, ideally ones the customer names, checking there is enough traffic per customer for alerts to mean something, and using anonymised identifiers rather than customer names in monitoring.
When the budget runs out
A target only changes behaviour if you agree in advance what happens when it is missed, in an error budget policy. Below is one possible sliding scale, offered as an illustration to adapt.
| Error budget left | Effort on reliability work (illustration) |
|---|---|
| Plenty | 10–15% as a baseline |
| Less than about 25% | Ramping up |
| None left | About 50% |
| Well over budget | Close to 90% |
Other practical options include reviewing target performance at each sprint retrospective, gating releases on the remaining budget rather than shipping on a fixed schedule, and resetting the budget monthly while letting fix-it work carry on past the reset. For alerting, our default is two alerts per target: a page when 2% of a 30-day budget is used within one hour, and a ticket when 10% is used within three days. Not every service needs a target, and some targets are better tracked in a monthly report than alerted on.
How we apply this
Our reliability work starts with a target-setting session: your product and business owners decide how reliable each service needs to be, and we measure it from your users’ side and write down what you decide. In the first 90 days we agree targets for your most important service and rebuild alerts around them, paging on how fast a service is using up its agreed allowance for failure rather than on fixed thresholds. Each quarter we then agree one or two reliability goals with you, each with a target and a date. See how reliability work fits into cover