Start from the user's journey, then pick the SLI type

Measuring speed and reliability introduced SLIs, SLOs, SLAs and the nines. Here you apply them to one service you own: the Mangrove app's checkout. The first decision is what to measure, and the answer starts with the user, not the servers. A user journey is a thing a customer is trying to get done. For checkout there are three that matter most:

• Place order: the customer taps "Place order" and the API gateway, the order service, the stock service and PostgreSQL create the order.
• Pay: the payment service charges a card, a mobile wallet like M-Pesa, UPI or GCash, or records cash on delivery.
• Track: after paying, the customer watches the order and the rider on the map.

Each journey needs a different kind of SLI. The SRE Workbook groups them by what the system does. For request-driven systems the usual types are availability and latency. For pipelines and background work they are freshness and correctness. Checkout has both:

Notice that the payment SLI counts a card declined by the customer's bank as good. The system did its job: it gave a clear, correct answer. A payment that hangs in "pending" for ten minutes, or charges the customer twice, is bad, even if every HTTP request in it returned 200. Correctness SLIs often come from a reconciliation job that compares your records with the payment provider's, so they arrive minutes late. That is fine for an SLO measured over weeks.

Keep the list short. The Workbook suggests five or fewer SLIs for a service. Four SLIs across three journeys is enough for checkout; a fifth for browsing the catalogue would belong to a different service.

Good events over valid events, measured in the right place

Write every SLI as a ratio: good events ÷ valid events, over a window. The ratio is always between 0% and 100%, and the error budget falls straight out of it. The two halves need separate decisions.

Valid events are the ones you are responsible for. A customer who enters an expired coupon gets a 422 response. That is the system working, so it is not valid for the availability SLI: it counts as neither good nor bad. The same goes for health checks, synthetic probes and load tests, which are not customers. A 429 Too Many Requests is different. Your rate limiter refused a real customer (Rate limiting), so it is valid and it is bad.

Good events are valid events that went well enough: no 5xx, no 429, and for the latency SLI, an answer within the threshold. Write latency as a ratio too: "99% of place-order requests answered within 2 seconds", rather than "p99 under 2 seconds". Both say the same thing, but the ratio form gives you a count of bad events, and that count is what the budget is made of.

Next, decide where to count. The same journey looks different from different places, and each place has a blind spot:

• The load balancer or API gateway sees every request that reaches you, with status and duration, and you already have its metrics. It cannot see requests that never arrive: a broken CDN certificate, a DNS problem, a mobile network that drops the connection.
• The client, meaning telemetry from the Mangrove app itself, is closest to what the customer feels. It is also noisy (weak mobile signal looks like your failure), arrives late (phones upload when they reconnect), and needs code and infrastructure of its own.
• A synthetic probe places a fake order with a test card every minute, day and night. It catches a total outage at 4 a.m. when there is no real traffic, but it follows one path, so it misses failures that hit only some users.
• Service logs inside the order service are the easiest to add, and the worst for SLOs: when the gateway times out and returns 502, the order service may log a success.

A practical setup: compute the SLO from gateway metrics, because they are complete for everything that reaches you and cheap to keep for 30 days. Run a synthetic probe so a silent outage at night still shows up. Compare the gateway SLI with client telemetry every week. If the app sees 98.7% while the gateway sees 99.95%, something between the phone and the gateway is failing, and your SLO is blind to it.

Choosing the target: data, users and the cost of each nine

Start from data. Compute the SLI for the last 90 days with the exact definition you just wrote. Say place order was at 99.96% in normal weeks. A target of 99.9% sits a little below that: normal noise will not spend the whole budget, but a real regression will show up within days. A target above what you achieve today is a wish, and it puts the team in a freeze on day one.

Then check the target against your dependencies. Every request to pay goes through the payment provider. If its SLA promises 99.95% a month, your pay SLI cannot reliably beat 99.95% unless you add a fallback, such as a second provider or offering cash on delivery when card payments fail. Measuring speed and reliability shows why parts in series multiply. Read the SLA closely, too. SLAs often exclude planned maintenance, count only incidents you report, and use calendar months. Your SLO is your own internal target; their SLA is a contract about money.

The same logic runs the other way. If Mangrove ever signs an SLA, for example with partner shops, set it looser than the internal SLO. The SLO is the early warning: you notice and fix problems while you still owe nobody anything.

Finally, price each extra nine. The SRE book warns that each step up in reliability can cost far more than the one before. Over 30 days (43,200 minutes), the budget for a full outage shrinks fast, and what you must build changes with it:

Users also set a ceiling. Many customers order over patchy mobile data, and their own connections fail more often than once in a thousand tries. They retry, and the order goes through. Going from 99.9% to 99.99% for them is mostly invisible, while the engineering cost is very visible. Pick the lowest target at which customers stay happy, and spend the rest on shipping.

The window and the budget, in minutes and in requests

An SLO is always measured over a window. A calendar month matches business reports, but it resets on the 1st: an outage on the 30th vanishes two days later, and the team feels free to take big risks early in the month. A rolling window always covers the last 28 or 30 days, so a bad day keeps counting until it slides out the back. The SRE Workbook recommends a four-week rolling window as a good general choice. Twenty-eight days has one more advantage: it holds exactly four of every weekday, so busy Fridays and quiet Tuesdays weigh the same in every window. Mangrove uses 30 days because it matches how people talk; either is fine if you are consistent.

The error budget is 1 − SLO of the window. You can express it two ways, and they give different answers:

• Time-based: 0.1% of 30 days is 43.2 minutes. Easy to explain, and it matches how people remember outages.
• Request-based: 0.1% of the valid requests. At about 60,000 orders a day, 30 days is about 1.8 million attempts, so the budget is about 1,800 failed orders.

The request-based form is the one to use for checkout, because it weighs failures by how many customers felt them. An outage at 4 a.m. and one at 7 p.m. cost the same minutes, but the evening one hits far more customers. During a festival rush the difference becomes dramatic, as the box below shows. One more detail: count each checkout attempt once. During a retry storm, every failed attempt can turn into several requests, and counting raw requests multiplies both halves of the ratio.

The error budget policy: what happens when it is spent

A budget with no rule attached is a dashboard nobody acts on. The error budget policy is a page that the engineering manager, the product manager and the people on call agree on and sign before anything goes wrong. On the day the budget runs out, nobody negotiates. Everyone reads the page.

A good policy answers five questions:

1. What happens at each level? Mangrove's checkout policy has four: more than 50% left, ship normally; 25–50%, risky changes (payment code, schema migrations, config on the checkout path) need an SRE reviewer and a tested rollback; under 25%, new features wait and only low-risk changes ship; budget spent, freeze everything except urgent fixes, security fixes and reliability work until the 30-day SLI is back above target. The example policy in the SRE Workbook uses the same idea: once the budget for the last four weeks is gone, it halts all changes except the most urgent fixes and security fixes.
2. Who decides? Ken, the engineering manager, applies the policy. Imran, the product manager, can ask for an exception. Disagreements go one level up, and the Workbook's example sends them to the CTO. A name, not "the team".
3. What are the exceptions? A release that fixes reliability always ships. A legal or security deadline ships with Ken's written approval and a rollback plan. A promotion booked with suppliers months ago can ship behind a feature flag, with someone watching the SLI during the rollout.
4. What if someone else spent it? The Workbook's example lets a team keep shipping features when another team's service or a company-wide network problem caused the miss. But if the postmortem shows checkout depended too hard on that service, making checkout survive it becomes the reliability work. For the payment provider, that means timeouts, a circuit breaker and a fallback (Timeouts, retries and circuit breakers), not waiting for them to improve.
5. When does one incident need more? The Workbook's example asks for a postmortem with at least one top-priority action whenever a single incident uses more than 20% of the four-week budget. Postmortems and learning covers that process.

The policy also changes the conversation with product. When the budget is healthy, the SLO is an argument for shipping: Imran can release the new wallet flow a week before the festival, because a few bad requests are affordable. When the budget is gone, he does not need to be persuaded; the page he signed already says what happens.