FDE Foundations · Module 10: Reliability
SLOs That Mean Something
An SLO is a promise about the user's experience: measured, bounded, and used to make trade-offs through its error budget. Vague SLOs are marketing.
11 min reading
Objectives
- Define SLIs from the user's experience
- Set SLO targets with error budgets
- Use the budget to decide feature vs reliability work
SLIs from the user's seat
Measure what the user feels: success rate of invoice submissions, p95 latency of the search endpoint, freshness of the nightly report at 6 a.m. Infrastructure metrics (CPU, memory) inform debugging but belong in dashboards, not promises.
Targets and budgets
Set targets the business needs, not perfect ones: 99.5 percent success over 30 days may be exactly right. The complement is the error budget: 0.5 percent of requests may fail. The budget converts reliability from a feeling into arithmetic: budget remaining means ship features; budget exhausted means fix reliability first, and everyone agreed to this rule in advance.
The FDE angle
At a customer, propose SLOs in their operating language: "The matching service will complete 99.5 percent of daily batches before 6 a.m.; breaches page you and open a joint ticket." SLOs you define together become the shared, objective referee for the whole engagement.
Keep them few
Three SLIs beat ten. Each needs an owner, a measurement query, and a review cadence. If nobody reads the SLO report, the SLO is decoration, and you should cut it or fix the report.
Quick check
An optional 2-3 question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Exercise
Write SLOs for a fictional document-service: three SLIs measured from the user's seat, targets with windows, the error budget arithmetic, and the agreed consequence when the budget empties.
Pass criteria
Three SLIs user-experience-based, targets with explicit windows, budget arithmetic correct, and the empty-budget consequence states who does what.