SLO
37 bites tagged SLO — interview questions with model answers, and 60-second explainers.
Monitoring with SLOs and error budgets
Define SLIs from the user's view, set SLO targets, derive an error budget, and alert on burn rate rather than raw thresholds. SRE reliability targets. paging on every CPU blip with no link to user impact.
Monitor p99 improvement from 500ms to 200ms and side effects
Tests systems-thinking on tail-latency instrumentation and metric tradeoffs. Strong answers cover histogram metrics, distributed tracing for fan-out bottlenecks, and guarding error rates, cost.
What specific metrics define a 'fast' report export?
Propose user-facing latency percentiles and throughput; split SLI from SLO target; pick realistic targets. Turning vague promises into precise SLIs and SLOs. Only infra metrics like CPU, not user latency.
Escalation Policy: When to Stop Shipping and Start Fixing
An escalation policy is a pre-agreed plan for when to divert engineers from feature work to fix reliability. When a service's error budget burns too fast, the policy's thresholds trigger specific actions. The footgun is thinking a quick rollback is enough.
Error Budget Burndown: Your Service's Reliability Fuel Gauge
An error budget burndown chart is a fuel gauge for your service's reliability. It shows how much 'allowable downtime' you've used, helping you decide when to ship features versus fix bugs. The footgun is ignoring a steep burn rate until it's too late.
SLO Burn Rate: Alerting on Budget Consumption
SLO burn rate measures how fast you're using your error budget. A burn rate of 2 means you're consuming budget twice as fast as allowed. It's used to trigger alerts for both fast outages and slow-burning problems to prevent SLO breaches.
SLO Document: Your Service's Reliability Contract
An SLO document is the source of truth for a service's reliability promises, acting as a formal contract between teams on what 'good enough' looks like. It defines measurable targets for availability and latency, guiding engineering priorities.
SLO Time Windows: Choosing Your Measurement Period
An SLO's time window is the calendar for grading reliability. A short window forces rapid fixes, while a long one smooths out blips for strategic planning. The footgun is using calendar months, which have unequal lengths and complicate budget math.
Error Budgets: The Currency of Reliability
An error budget is the acceptable amount of downtime or errors your service can have over a period. Calculated as (1 - SLO), it's a currency for balancing risk (new features) and reliability work. The main footgun is treating it as a target to spend.
Service Level Agreement (SLA): The Contract Behind Uptime
An SLA is a business contract, not a technical target. It defines the minimum service quality a provider promises a customer, with financial penalties for failure. You see them in every cloud provider contract.
Error Budgets: Balancing Reliability and Innovation
An error budget is your service's allowance for unreliability, calculated as 1 minus the SLO. It provides a data-driven signal for when to halt new feature releases and focus on stability, protecting users from repeated SLO misses.
Service Level Indicators: Measuring What Matters
An SLI is a direct measurement of your service's performance, like request latency or error rate. It's the raw data that forms the basis for reliability goals (SLOs). The main footgun is measuring system internals instead of the actual user experience.
Embracing Risk: Reliability Is a Budget, Not a Goal
Instead of chasing 100% uptime, SRE treats reliability as a budget. The acceptable downtime, or 'error budget,' is permission to take calculated risks like shipping features faster. The footgun is wasting resources on reliability users won't even notice.
Get SLO bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.