SLO
37 bites tagged SLO — interview questions with model answers, and 60-second explainers.
Platform team metrics versus product team metrics
Measure adoption, reliability SLOs, integration time, and self-service ratio over user engagement. platforms serve developers, not end users. copying consumer metrics like DAU onto a platform with no end users.
First-SRE 90-day plan at a startup
Listen and measure first, pick one high-impact service, define SLIs/SLOs and basic alerting, then show reduced toil or incidents to leadership. Whether you can introduce SRE incrementally and show value.
Calculating downtime for a 99.9% SLO
0.1% of 30 days is roughly 43 minutes of allowed downtime; healthy budget enables faster shipping while depletion slows or freezes deploys. Whether you can compute and apply an error budget.
Designing an error budget policy
Define SLO and budget, tiered consequences as burn worsens, a feature freeze on exhaustion, and concrete earn-back criteria. Whether you can make SLOs enforceable, not decorative.
What is an error budget and how is it used?
The budget is the allowed unreliability (100 percent minus the SLO); track its burn, ship freely when budget remains, and freeze risky changes to focus on reliability when exhausted. Understanding error budgets as a release governor.
Defining SLIs and an SLO for an auth service?
Pick user-centric SLIs like login availability and latency, measure good over valid events at the right boundary, then set an achievable SLO with a window. Translating user needs into measured reliability.
What is an SLO and how do you define API availability?
SLO is a target on an SLI, availability SLI is good requests over valid requests, you need labeled request counts over a window. Understanding SLI versus SLO and how to measure reliability.
Measuring post-incident review effectiveness
Track action-item completion and age, repeat-incident rate, time-to-publish, and MTTR trend. Treating the review process as a measurable system.
Designing a SEV1-SEV4 severity matrix
Tie levels to user impact, scope, and SLO burn with concrete thresholds; map each to response and escalation. Measurable severity definitions. subjective severity with no metrics, causing under or over reaction.
SLO-based alerting and error budgets
Define SLI/SLO, derive an error budget, alert on how fast you burn it using multi-window multi-burn-rate rules so fast burns page and slow burns ticket. alerting on budget burn rate, not static thresholds.
Symptom-based versus cause-based alerting
Symptom alerts fire on user impact like high error rate or latency; cause alerts fire on internal conditions like high CPU. Page on symptoms, treat causes as diagnostic. understanding why user-facing symptoms make better pages.
Writing SLIs in PromQL
Availability is good requests over total using rate and non-5xx counters; latency uses histogram_quantile over rate of buckets summed by le. turning SLOs into correct PromQL.
Fixing watermelon SLOs that hide unhappy users
Green-outside, red-inside SLOs come from server-side measurement, coarse aggregation, wrong events, and lax thresholds; fix by measuring at the client and using meaningful SLIs. Whether SLIs truly track user experience.
Setting SLOs across a dependency chain
Serial dependencies multiply, so each backend needs a tighter SLO than the target; mitigate with redundancy, caching, and graceful degradation. Reliability math across dependencies.
Handling planned maintenance in SLOs and error budgets
Either charge maintenance to the error budget or formally exclude it via a maintenance window; each trades honesty against fairness. Honest accounting of planned downtime.
Defining SLOs for a new critical service
Start from user journeys, pick SLIs, involve product, engineering, and business stakeholders, set realistic targets iteratively. Cross-functional SLO design.
Proposing availability and latency SLIs for an auth API
Availability as the ratio of successful valid requests; latency as the fraction served under a threshold; measure at the edge from the user's view. Designing measurable, user-centric SLIs.
What is an error budget?
Error budget is one minus the SLO, the allowed unreliability; it gates feature velocity versus reliability work. Linking reliability targets to delivery decisions.
Relationship between SLI, SLO, and SLA
SLI is the measured metric, SLO is the internal target for that metric, SLA is the external contract with consequences. Core reliability vocabulary. Treating the terms as synonyms or making the SLO looser than the SLA.
Symptom-based vs cause-based alerting
Symptom alerts fire on user-visible impact, cause alerts on internal conditions; page on symptoms to cut noise and catch unforeseen failures. Alerting philosophy and pager hygiene.
Error budget policy across dependent microservices?
Set per-service SLOs but anchor on user-facing journey SLOs, budget for dependency error via the multiplication of availabilities, attribute downstream-caused failures correctly, and use… SLO design in a dependency graph.
Error budget exhausted early: what now?
Invoke the error budget policy, shift focus from features to reliability, prioritize stability work, analyze what burned the budget. whether you use the error budget as a decision tool, not punishment.
How do you set SLOs for a service from scratch?
Identify critical user journeys, pick SLIs that reflect user happiness, measure current performance, set achievable targets with buffer, iterate. a disciplined, user-centric process for defining reliability targets.
SLI vs SLO vs SLA: how do they relate?
SLI is a measured metric, SLO is the internal target for that metric, SLA is the external contract with consequences. command of the core reliability vocabulary.
Get SLO bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.