Module 2: Slis Slos And The Error Budget

1. Introduction: from vocabulary to math

Description

Module 1 gave you three things: the complete SRE vocabulary, always quoted from the official source; a real risk inventory over andes-cargo-infra/, read for the first time through a reliability lens; and a number — 33.3x — calculated by hand, once, over a single incident. That manual calculation (lesson 6 of that module) was deliberate: a complete operation, really executed, but single-use — four fixed variables, one result, with no way to reuse it with a different SLO or a real traffic dataset without rewriting the whole script. This module generalizes exactly that arithmetic into a real tool: scripts/error_budget_calculator.py, which you're going to build in lesson 4 and extend in lessons 6 and 7, and which keeps running, with no fundamental changes, all the way to the Module 8 capstone.

Along with Module 3, this is the module with the most executed weight in this whole guide. No lesson in this module describes SRE math in prose without running it: every formula that appears here — SLI, error budget in minutes, burn rate — translates into real Python code, run with python3 over a fixed, committed dataset, with the literal output pasted into the lesson. You'll be able to copy each script, run it yourself, and get exactly the same result, always — the same determinism guarantee you already saw in Module 1, now applied to a complete tool, not a one-time calculation.

Connection to the module

This module's eight lessons follow a strict progression, each built on the one before it. Lesson 2 gives the missing vocabulary for choosing a good SLI — Google SRE's four golden signals — applied to process-shipment-manifest. Lesson 3 applies the exact formula (good events ÷ valid events) in writing, deciding with judgment what counts as each thing for that specific Lambda — the step no calculator can automate, because it depends on business judgment, not arithmetic. Only in lesson 4 does the code appear: error_budget_calculator.py, run over a fixed 30-day traffic dataset, with the module's first literal output. Lesson 5 uses that same tool to compare three different SLOs over the same real data, showing in numbers — not theory — why the SLO matters as much as the SLI. Lesson 6 extends the calculator with burn rate, the piece Module 4 is going to turn into a real alert. Lesson 7 runs the complete tool over a second dataset, hand-designed to represent a genuinely bad week. And lesson 8 closes with SLO.md: the document that sets, with evidence and not a hunch, Andes Cargo's real SLI and SLO — the same document RELIABILITY-CHARTER.md left as an Open row on its map, and that Module 3 onward is going to measure and cite without reopening the discussion.

Analogy: from the prepaid card to the mobile data plan

You already know Module 1's prepaid card: an error budget is a fixed monthly balance, spent fast or slow, but never replenished early. That analogy explains how much balance is left pretty well. What it doesn't explain as well is the question this module adds, especially in lesson 6: how fast are you spending it right now?

For that, a mobile data plan is more useful than a prepaid card. Both represent a fixed monthly cap — say, 20 GB a month, not replenished early — but a data plan has something a prepaid card doesn't need: a meter you check mid-month to know if you're on track. If you've used 10 GB by day 15, you're exactly on the expected pace — you'll hit 20 GB right on day 30. If you've used 18 GB by day 5, something changed: at that rate, you'll run out of data before the first week is even over, well before the total balance hits zero. The figure that matters at that moment isn't "how much is left" — technically, 2 GB is still left — it's the rate it's being spent at, because that rate is what tells you whether you'll make it to the end of the month or not. That rate, applied to a system's error budget, is exactly what this module calls burn rate: not the balance, but the consumption rate, measured against the rate the SLO allows.

You're going to see this distinction with real numbers in lesson 6: two days from the same dataset, same SLO, with the same technically-positive remaining monthly balance — but one of those days spent data at a rate that, sustained, would have exhausted the entire month within hours.

This module's map: the 8 lessons

   MODULE 2 — SLIs, SLOs, AND THE ERROR BUDGET
   from the formula in prose to the calculator that really runs

   M2.1  Introduction (this lesson)             the map, the promise of the tool
   M2.2  The 4 golden signals                    what to measure, with real Andes Cargo examples
   M2.3  Your first SLI definition                good/valid, decided in writing
   M2.4  The error budget calculator              EXECUTED: first real run
   M2.5  Choosing an SLO that means something      EXECUTED: 3 scenarios, same data
   M2.6  Burn rate: the speed, not just the balance EXECUTED: the calculator extended
   M2.7  A real Andes Cargo scenario                EXECUTED: second dataset, a bad week
   M2.8  Project: SLO.md                              EXECUTED: the document M3-M8 measure against

#	Lesson	What it builds
1	Introduction (this one)	The map; picks up Module 1's 33.3x; promises the reusable tool
2	The four golden signals	Latency, traffic, errors, saturation — each applied to `process-shipment-manifest`
3	Your first SLI definition	Good vs. valid, decided with judgment, applied in writing
4	The error budget calculator	`scripts/error_budget_calculator.py`, run over 30 days of fixed traffic
5	Choosing an SLO that means something	The same calculator, three SLOs, the same real data
6	Burn rate	The calculator extended with the formula from `sre.google/workbook/alerting-on-slos/`
7	A real Andes Cargo scenario	The calculator over a second dataset: a bad week, hand-designed
8	Project: `SLO.md`	The document with Andes Cargo's real SLI, SLO, and error budget

What you already have, and what's still missing

Before writing a single line of Python, it's worth being precise about what you inherit from Module 1 and what's genuinely new here:

You already have, from Module 1:

The complete vocabulary — SLI, SLO, SLA, error budget, toil, on-call, postmortem — quoted from Google SRE (lesson 7 of that module).
The error budget formula in minutes: error_budget = (1 − SLO) × window_minutes, already applied by hand in lesson 6 of that module.
A reference number: with a hypothetical 99.9% monthly SLO, the budget is 43.2 minutes — and the Claude Code incident consumed 33.3 times that in a single event.
RELIABILITY-CHARTER.md, with a row explicitly marked Open: "What SLI and SLO make sense for process-shipment-manifest, with evidence?" — the exact question this module answers.

Still missing, and what this module builds:

A real SLI, not a hypothetical one, defined with judgment about what counts as "good" and what counts as "valid" for process-shipment-manifest — never copied from a generic blog example.
A tool that accepts any SLO, any time window, and any traffic dataset — not a single-use script like lesson 6 of Module 1's.
The burn rate formula, which Module 1's manual calculation never needed (it compared a single, already-finished incident against a fixed budget; burn rate exists, specifically, to detect dangerous consumption while it's still happening).
Andes Cargo's first real SLO, with its justification, written into SLO.md — not a hypothetical value "to demonstrate the arithmetic" like Module 1 lesson 6's 99.9%, but the real decision that governs the rest of this guide.

Common mistakes

Assuming this module already knows Andes Cargo's SLO starting in lesson 1 (jumping ahead). What happens: someone, reading this module's map, expects lesson 2 or 3 to already mention a concrete SLO number for Andes Cargo. How to spot it: if you look for a specific availability percentage for Andes Cargo before lesson 5 of this module. How to fix it: the real SLO gets chosen only in lesson 5, after having a well-defined SLI (lesson 3) and a calculator running on real data (lesson 4) — exactly the same discipline RELIABILITY-CHARTER.md already defended in Module 1: no number gets chosen without evidence first.

Treating Module 1's manual calculation and this module's calculator as redundant (underestimating the leap). What happens: someone thinks "I already did this math by hand, why do it again in Python?" How to spot it: if your reasoning is "the result is going to be the same either way." How to fix it: Module 1 lesson 6's script had four fixed variables, hardcoded inside the code itself — changing the SLO meant editing the script line by line. This module's calculator accepts a real traffic dataset (not a single "24 hours" figure), and its functions get reused unchanged in Module 3 (with real CloudWatch data), Module 4 (with burn rate as an alert), and Module 8 (capstone). The difference isn't the result of a one-off calculation — it's that one is a tool and the other was, on purpose, a single-use calculation.

Thinking burn rate is just "another way of saying the same thing" as the error budget (merging two distinct concepts). What happens: someone, reaching lesson 6, assumes burn rate is simply the error budget expressed in different words. How to spot it: if you can't explain the difference between "how much budget is left" and "how fast it's being spent right now" without using the word "budget" in the second part. How to fix it: this lesson's analogy separates them precisely — the data plan's balance (error budget) and the consumption rate (burn rate) are two different numbers, calculated with different formulas, that can give opposite readings at the same time: a month can end with a positive balance (error budget > 0) while having had, at some point, a dangerously fast consumption streak (high burn rate) that a glance at the final balance would never have revealed. Lesson 6 measures exactly that streak, with real numbers.

Exercises

Exercise 1 — Explain, without looking back, what Module 1 lesson 6's script was missing to be "the calculator" this module promises. Name at least two concrete limitations of that script that this module's tool is going to solve.

See solution

Two real limitations, among several possible ones: (1) the SLO, the window, and the incident's duration were hardcoded directly into the code (SLO = 0.999, INCIDENT_HOURS = 24) — testing a different SLO meant editing the script, not passing a parameter; (2) the script only accepted a single duration figure (24 hours), not a real traffic dataset with many days of data — there was no way to calculate an SLI from good and valid events, because the script never received that kind of data. This module's calculator solves both: its functions accept a traffic dataset (a list of valid/good events per day) and an SLO as a parameter, not as a fixed constant in the code.

Exercise 2 — Apply the data plan analogy to a concrete situation, without doing any calculation yet. A 20 GB monthly data plan shows, on day 20 of the month, cumulative usage of 13 GB. Using only this lesson's intuition (no formulas yet, those arrive in lesson 6), does that usage by itself tell you whether the current pace is sustainable through the end of the month? What additional information would you need?

See solution

No, the cumulative balance alone doesn't tell you — 13 GB out of 20 GB on day 20 of, say, a 30-day month is actually below the expected pace (you'd expect 20 × 20/30 ≈ 13.3 GB if usage were perfectly even), so at first glance it looks healthy. But that same cumulative figure doesn't distinguish between "it was spent evenly all month" and "12 GB was spent all at once yesterday, and barely anything the rest of the month" — two completely different stories with the same cumulative balance. The additional information needed is, exactly, the consumption rate over a recent, short window (say, the last 24 hours), not the accumulation since the start of the month — the same distinction between error budget (cumulative) and burn rate (recent rate) that lesson 6 of this module calculates with real numbers.

Exercise 3 — Name, from memory, the exact order of this module's eight lessons and why that order can't be reversed. In particular, explain why lesson 3 (defining the SLI) has to happen before lesson 4 (running the calculator), even though the calculator, technically, doesn't need any definition text to run.

See solution

The order: (1) introduction, (2) four golden signals, (3) SLI definition in writing, (4) error budget calculator, (5) choose SLO, (6) burn rate, (7) real scenario, (8) SLO.md. Lesson 3 precedes lesson 4 not for a technical reason in the code — the calculator, in fact, only needs numbers, it doesn't care where they came from — but for a rigor reason: without first deciding, with explicit judgment, what counts as a "good event" and what counts as a "valid event" for process-shipment-manifest, any number the calculator produces in lesson 4 would be arithmetically correct but conceptually hollow — an SLI nobody could defend if someone asked "why did you count that invocation as good?" Lesson 3 exists so that, by the time lesson 4 runs the script, every number in the dataset already has a justification decided beforehand, not invented to make the result look good.

Summary and next step

This lesson connected Module 1's manual calculation — 33.3x, a single incident, a single-use script — with this module's promise: a real, reusable calculator, accepting any SLO and any traffic dataset, built over the next seven lessons. You saw the complete map, the analogy that's going to govern lesson 6 (the mobile data plan: not just how much is left, but how fast it's being spent), and the precise list of what you inherit from Module 1 versus what's still left to build.

Before moving on you should be able to: name this module's eight lessons in order; explain, with at least two concrete reasons, why Module 1 lesson 6's script wasn't yet "the calculator"; and explain the difference between error budget (balance) and burn rate (speed) using the data plan analogy, without formulas.

Lesson 2 starts with any SLI's real starting point: before measuring anything, you have to know what to measure — Google SRE's four golden signals, each applied with a concrete example on process-shipment-manifest.

Resources

This same repository, Module 1, lesson 6 (06-hands-on-the-error-budget-the-claude-code-incident-burned.md) — the manual calculation this module generalizes.
This same repository, Module 1, lesson 8 (08-project-andes-cargos-reliability-charter.md) — RELIABILITY-CHARTER.md, with the Open row this module closes in lesson 8.
Google SRE Workbook — Implementing SLOs — the error budget formula this module generalizes into code.
Google SRE Workbook — Alerting on SLOs — the exact source for burn rate, formalized in lesson 6 of this module.

← Previous8. Project: Andes Cargo's reliability charter Next →2. Choosing a good SLI: the four golden signals