Reliability targets

QuickCart needs a number that says how reliable is reliable enough, and a rule for what to do when it isn’t.

Three terms, each built on the one before.

Choosing the SLI

A good SLI measures what users feel, at the thing they care about. For each important thing users do, ask two questions: did it work, and was it fast enough?

CPU use, memory and server counts are useful for engineers, but they aren’t SLIs. CPU can be at 90% while every customer is happy.

What the nines mean

The number of nines sounds small. The difference isn’t:

At 99.99%, one bad deploy that takes 20 minutes to undo uses the budget four times over. Each extra nine needs much more automation, more redundancy and more careful releases. Pick the lowest target your users would be happy with, not the highest you can say.

Spending the budget

The error budget turns an argument into a number. Failure you can afford is budget to spend: on releases, on experiments, on moving fast. The team agrees an error budget policy in advance:

This settles QuickCart’s argument. If there’s budget left, Sam is right: ship. If it’s gone, the founder is right: slow down. Nobody decides by who shouts loudest.

SLO or SLA?

An SLA, service level agreement, is a promise to customers with a penalty, usually money back, if you miss it. AWS publishes SLAs for its services. An SLO is your own internal target. Set your SLO tighter than any SLA you offer, so you find out you’re slipping before it costs you.

Pick an SLO, then make things go wrong. Watch how much each failure costs, and what the policy says to do. Try the same failures at 99% and at 99.99%.

What to notice: the same 20-minute outage is a small dent at 99%, half the budget at 99.9%, and four times the whole budget at 99.99%. The SLO you choose decides how much room you have to move fast.

Free — everything runs on your laptop, on a sample log file.

You’ll measure an availability SLI and a speed SLI from a web server’s log, using only grep. Then you’ll scale it up to a month and decide whether QuickCart met its SLO. About 20 minutes.

1. Make a folder and a log file

   TerminalCopy

   mkdir quickcart-slo

   Part	What it means
   mkdir	make a directory
   quickcart-slo	its name

   TerminalCopy

   cd quickcart-slo

   Part	What it means
   cd	move into a directory. Later commands run in here
   quickcart-slo	the folder you just made

   In your editor, create a file called requests.log in that folder, and paste this in. Each line is one request to QuickCart’s API: the time, the method, the path, the status code, and how long it took.

   requests.logCopy

   2026-09-25T12:00:01Z POST /orders 201 184ms
   2026-09-25T12:00:02Z GET /menu 200 41ms
   2026-09-25T12:00:02Z GET /orders/1042 200 63ms
   2026-09-25T12:00:03Z POST /orders 201 212ms
   2026-09-25T12:00:04Z GET /menu 200 38ms
   2026-09-25T12:00:05Z POST /orders 503 3002ms
   2026-09-25T12:00:05Z GET /menu 200 44ms
   2026-09-25T12:00:06Z POST /orders 201 197ms
   2026-09-25T12:00:07Z GET /orders/1043 404 22ms
   2026-09-25T12:00:08Z POST /orders 201 1480ms
   2026-09-25T12:00:08Z GET /menu 200 40ms
   2026-09-25T12:00:09Z POST /orders 500 95ms
   2026-09-25T12:00:10Z GET /menu 200 39ms
   2026-09-25T12:00:11Z POST /orders 201 176ms
   2026-09-25T12:00:12Z GET /orders/1044 200 58ms
   2026-09-25T12:00:13Z POST /orders 201 203ms
   2026-09-25T12:00:13Z GET /menu 200 42ms
   2026-09-25T12:00:14Z POST /orders 201 188ms
   2026-09-25T12:00:15Z GET /menu 200 37ms
   2026-09-25T12:00:16Z POST /orders 201 1120ms

   Real logs have millions of lines, but the counting works exactly the same way.

2. Count the orders

   QuickCart’s SLI is about placing orders, which are the POST /orders lines.

   TerminalCopy

   grep -c "POST /orders" requests.log

   Part	What it means
   grep	search a file for lines containing some text
   -c	print only how many lines matched, not the lines themselves
   "POST /orders"	the text to look for
   requests.log	the file to search

   You should see

   10

   Ten order attempts: that’s the total for the SLI.

3. Count the failed orders

   A failure is a status code in the 500s: QuickCart’s fault, not the customer’s.

   TerminalCopy

   grep -E "POST /orders 5[0-9][0-9] " requests.log

   Part	What it means
   grep	search for matching lines
   -E	the search text is a pattern, not plain text
   POST /orders 5[0-9][0-9]	POST /orders, a space, then a 5 followed by any two digits, then a space: a status from 500 to 599
   requests.log	the file to search

   You should see

   2026-09-25T12:00:05Z POST /orders 503 3002ms
   2026-09-25T12:00:09Z POST /orders 500 95ms

   Two failed orders. The 404 for /orders/1043 isn’t counted: it isn’t an order attempt, and a 404 means the request asked for something that doesn’t exist, which isn’t a failure of QuickCart.

   Availability SLI = good ÷ total = (10 − 2) ÷ 10 = 80%. A terrible minute.

4. Count the slow orders

   QuickCart’s SLI also says in under one second. A duration with four or more digits, like 1480ms, is a second or more.

   TerminalCopy

   grep -c -E "POST /orders 2[0-9][0-9] [0-9]{4,}ms" requests.log

   Part	What it means
   grep -c -E	count the lines matching a pattern
   POST /orders 2[0-9][0-9]	a successful order: status 200 to 299
   [0-9]{4,}ms	four or more digits, then ms: 1000 milliseconds or more
   requests.log	the file to search

   You should see

   2

   Two orders worked, but took over a second. For QuickCart’s full SLI, succeeded in under one second, the good orders are 10 − 2 failed − 2 slow = 6. That’s 60%.

5. Scale it up to a month

   A minute of log shows how to count, not whether QuickCart met its target. Here are a full month’s numbers, counted the same way:

   Count	September
   Order attempts	1,200,000
   Failed or slower than one second	1,450
   Good	1,198,550

   Work out three numbers. You can use the calculator on your computer.

   Question	Working	Answer
   What was the SLI?	1,198,550 ÷ 1,200,000	99.88%
   How big was the error budget, at a 99.9% SLO?	0.1% of 1,200,000	1,200 bad orders
   How much of it was used?	1,450 ÷ 1,200	121%: over budget

   You should see

   QuickCart missed its 99.9% SLO in September, by 250 orders. Under the policy in the idea, feature releases pause until the budget recovers.

6. Write your own SLO

   For an app you work on, fill this in. It works for a mobile app’s crash-free sessions as well as for an API.

   Question	Your answer
   What’s the most important thing users do?
   What counts as a good event? A bad one?
   How will you measure it, and where?
   What target, over what window?
   What does the team do when half the budget is gone? And all of it?

7. Clean-up step: Clean up

   Move out of the folder, then delete it:

   TerminalCopy

   cd ..

   Part	What it means
   cd ..	move up one level, out of quickcart-slo

   TerminalCopy

   rm -r quickcart-slo

   Part	What it means
   rm	remove files. There’s no bin: they’re gone straight away
   -r	recursive: remove the folder and everything inside it
   quickcart-slo	the folder to remove. Check the name before you press Return

   Nothing was created on AWS, so there’s nothing else to delete.