Service Level Objectives & Error Budgets

Module 2 of the DevOps Institute's SRE Foundation (SREF) syllabus is the module the rest of the exam quietly leans on — postmortems, toil, and monitoring all eventually cash out in the same currency this module defines. This page treats the material the way the exam actually asks about it: as precise, single-best-answer distinctions rather than a general discussion. You'll leave with the exact SLA/SLO/SLI boundary, the arithmetic that turns an SLO target into a spendable number, and what a properly written error-budget policy is supposed to force a team to do once that number hits zero. For the full worked definitions, the guidance on choosing good SLIs, and the plain-language derivation, see SLIs, SLOs & error budgets in the Foundations track — this page assumes you've read it or will read it alongside this one, and stays focused on how DevOps Institute phrases and tests the same ground.

What SREF Module 2 actually tests

☺ Like you're 10: The test doesn't ask you to build anything — it asks you to correctly label three lookalike ideas and do one small piece of math, over and over, with no notes.

The SRE Foundation is a closed-book, single-best-answer paper — 40 questions in 60 minutes, 65% to pass, no partial credit, no live terminal. Within that format, Module 2 tends to surface in three recognisable stem shapes. The first is definitional: "Which of the following best describes an SLA?" — a straight vocabulary check with three plausible-sounding wrong answers built from the other two terms. The second is arithmetic: give you an SLO percentage and a window, and ask for the resulting error budget in minutes or requests. The third is situational: describe a team whose budget is exhausted and ask what a properly implemented error-budget policy requires next, with at least one tempting-but-wrong option that "solves" the problem by moving the target instead of meeting it.

DevOps Institute doesn't publish an official per-module question quota for the SREF paper the way some certification bodies publish domain weights — treat any specific percentage you see quoted online skeptically and verify current guidance on the vendor's own page before you register. What accredited courseware and repeated candidate reports agree on is that this module is disproportionately high-yield: SLIs, SLOs, and error budgets are the vocabulary every later module in the syllabus assumes you already have cold, from Reducing Toil's toil-versus-engineering-time tradeoffs to Anti-Fragility & Learning from Failure's postmortem framing. Get this module exactly right and several later ones get noticeably easier.

SLI, SLO, and SLA — the distinction the exam is built to test

☺ Like you're 10: One is the measurement, one is your own goal for that measurement, and one is the promise you sign with someone else — mixing any two of them up is the wrong answer.

Three terms, one chain

The exam expects you to place any given percentage or metric into exactly one of three buckets, correctly, on sight. The chain runs in a fixed order — you can't set a target before you have something to measure, and you can't sign a contract before you have an internal target to set it against:

Notice what each column is actually testing. "What it is" separates a raw measurement mechanism from a target value from a contract. "Who sets it" separates an engineering decision from a business one — the exam likes to ask who is responsible for a given number, and the SLA is the one answer that's never "the SRE team alone." "Worked example" is where most stems actually live: you'll be handed two or three percentages in a short scenario and asked to say which one is which, with no term named for you.

The trap: only one of the three has financial teeth

A stem that reads "which of these three commitments carries a penalty if missed" always resolves to the SLA — it's the only one of the three that's external and contractual. The SLO and the SLI are both internal: an SLO miss triggers your own error-budget policy (the subject of the rest of this page), not a check written to a customer. The exam also tests the direction of the gap between SLO and SLA: a well-run SLA is set looser than the internal SLO on purpose, so ordinary operational noise doesn't trigger a customer-facing penalty every time the team has a slightly rough week. A stem describing an SLA set tighter than the SLO, or identical to it, is describing a broken setup — with an SLA that tight, every SLO miss is simultaneously a contract breach, and the team has thrown away its own early-warning window. For how to actually choose a good SLI in the first place — the "few, user-facing, and boundary-measured" criteria — see SLIs, SLOs & error budgets; the instrumentation side of the SLI is covered in depth in Monitoring & Service Level Indicators, Module 4.

Deriving an error budget from an SLO target

☺ Like you're 10: Take 100%, subtract your target, and that leftover sliver is the exact number of minutes — or failed requests — you're allowed to spend before the policy kicks in.

The formula

Error budget = (100% − SLO) × window

time-based:     window expressed in minutes (or seconds) in the measurement period
request-based:  window expressed in total valid requests in the measurement period

The window matters as much as the percentage, and the exam knows it: an SLO stated without a window ("99.9% available") is incomplete, because the same percentage produces wildly different absolute numbers depending on whether it's measured over a day, a rolling 28 days, or a calendar month. Unless a stem says otherwise, assume a 30-day window and use 43,200 minutes (30 × 24 × 60) as the total — it's the round number the exam gravitates toward because the arithmetic stays clean.

Two worked examples

Time-based, across the SLO tiers you're most likely to see on the paper:

Request-based, the shape you'll see whenever a stem talks about success rate rather than uptime: a checkout API serves 5,000,000 requests over a 30-day window and carries a 99.9% success-rate SLO. Its error budget is 0.1% × 5,000,000 = 5,000 failed requests — for the entire 30-day window, not 5,000 per day. That scope trap is worth internalising on its own: a stem that quietly asks for a daily figure when it gave you a 30-day budget (or vice versa) is testing whether you noticed the window, not whether you can multiply.

What an error-budget policy actually enforces

☺ Like you're 10: The policy is the part written down in advance — before anyone's stressed about a launch — that says exactly what happens the moment the number hits zero.

An error-budget policy is a pre-agreed, written governance mechanism, signed off by both engineering and product/business stakeholders before anyone is under pressure — not negotiated in the moment during an incident review. A properly implemented one specifies at least three things: the trigger (commonly "budget fully consumed," sometimes an earlier warning threshold such as 75% spent with time left in the window), the enforcement action (freeze new feature launches and other budget-spending risk, redirect a defined share of engineering capacity to reliability work), and an exception path for genuinely urgent, low-risk changes — such as a security patch — that requires a named approver, not an ad hoc argument with whoever's on call that week. Google's own policy, the one that popularised the concept, is worked through with what actually happened the first time it froze a real launch in Google & the error-budget policy.

Budget remaining, on its own, doesn't tell you how urgently to react — a service can burn a 30-day budget flat in six hours or drip it evenly across the whole month, and those two situations demand completely different alerting responses even though they end at the same zero. The alerting math built specifically to detect the fast case early is covered in multi-window, multi-burn-rate alerting, and how the window itself (rolling versus calendar, and combining several SLOs into one composite target) changes this arithmetic is covered in SLO windows & composite SLOs. Neither is core SREF Module 2 territory, but both are the natural next stop once this module's arithmetic is automatic.

Try it in the exam's phrasing

☺ Like you're 10: Three questions in the exact single-best-answer shape you'll see on the real paper — pick one option, then check.

The SREF paper is entirely single-best-answer multiple choice: four options, exactly one correct, no partial credit for a well-reasoned wrong answer. The three questions below are written in that register. For a much larger bank drilled specifically on this ground, see Practice · SRE Principles, SLOs & Toil and the timed Drill — SLO & Error-Budget Calculation.

Q1. A payments platform's engineering team sets an internal target of 99.95% successful transaction processing, measured over a rolling 30-day window. Separately, the company's signed contract with its merchants promises 99.9% and includes service credits for any shortfall. What does the 99.9% figure BEST represent?

• A. The SLI
• B. The SLO
• C. The SLA
• D. The error budget

Q2. A service has a 99.9% SLO for request success rate, measured over a rolling 30-day window (43,200 minutes). Approximately how much downtime does the team's error budget allow for that window?

• A. 4.32 minutes
• B. 21.6 minutes
• C. 43.2 minutes
• D. 432 minutes

Q3. A team's error budget for the current SLO window has been fully consumed by a string of incidents, with eleven days left before the window rolls forward. According to a properly implemented error-budget policy, what is the standard next step?

• A. Immediately reassign the on-call engineers who were paged during the incidents.
• B. Lower the SLO target so the team is back within its now-smaller allowed error rate.
• C. Freeze new feature releases and prioritize reliability work until the budget recovers or the policy's exception process is invoked.
• D. Continue shipping at the normal release cadence, since the window will roll forward on its own regardless.

Where this leaves you in the blueprint

☺ Like you're 10: Every later module assumes you can do this module's math in your head — that's why it comes right after the principles module, not near the end.

Module 1, SRE Principles & Practices, gives you the philosophy this module turns into arithmetic. Module 3, Reducing Toil, spends the engineering time this module's budget is meant to protect. To practice the arithmetic itself under timed conditions, run the SLO & Error-Budget Calculation drill, or apply it to a real design decision in Capstone Part 1 — Define the SLOs. Keep the chain from this page as a filter for everything that follows: if a later module's example doesn't reduce to "some SLI, measured against some SLO, spending some error budget," it probably isn't SREF Module 2 territory, whatever it's labeled.