Service Level Indicators (SLIs) are quantitative measures of some aspect of the service provided to a customer. They define what you measure, such as latency, throughput, error rate, or availability. Service Level Objectives (SLOs) are target values for these SLIs over a specific period, defining the desired level of reliability. The error budget, then, is derived directly from the SLO and represents the maximum amount of acceptable unreliability or downtime allowed within the defined period without violating the SLO.
Defining SLIs and SLOs Effectively
To define effective SLIs, focus on what truly matters to the user experience. For a web service, common SLIs include request latency (e.g., P99 latency), request success rate (e.g., HTTP 2xx responses), and system availability. SLOs are typically set as a percentage, like “99.9% availability over 30 days” or “P99 request latency below 200ms for 99% of requests”. The error budget is then calculated as the inverse of the SLO; for 99.9% availability, the error budget is 0.1% of the total time in the measurement period. This budget allows teams to make data-driven decisions about the trade-off between shipping new features and improving reliability.
Best practice
Start by identifying user journeys and critical business functions. Define SLIs that directly map to these, prioritizing user-facing metrics over internal system metrics. Involve product and business stakeholders in setting SLOs to ensure they reflect actual customer expectations and business priorities, not just what is technically easy to achieve. Implement robust monitoring and alerting for your chosen SLIs and SLOs early in a service’s lifecycle.
Edge case interviewers probe for
An interviewer might ask what happens when your error budget is depleted. This signals that the team must halt or significantly reduce new feature development and dedicate engineering resources to reliability work, technical debt, or addressing the root causes of the unreliability. It forces a trade-off: innovation versus stability. They might also ask how to handle “cascading failures” impacting multiple services, which often requires defining SLIs/SLOs for dependencies.
Common mistake
A common mistake is setting SLOs too loosely, which doesn’t drive improvement, or too aggressively without understanding current performance baselines, leading to constant budget exhaustion and team burnout. Another error is selecting SLIs that are easy to measure but don’t reflect user experience, such as CPU utilization instead of request latency. Failing to communicate SLOs and their implications to product owners also causes friction when the error budget is consumed.
What the interviewer is checking
The interviewer is checking your fundamental understanding of SRE principles, particularly how reliability is defined, measured, and managed. They want to see if you can apply these concepts practically to a microservice architecture, balance reliability with feature velocity, and communicate effectively about these trade-offs with both technical and non-technical stakeholders.
Imagine you run a super popular pizza delivery service. An SLI is like measuring how hot the pizza is when it arrives at the customer’s door, or how long it took to get there. It’s a specific, measurable thing about your service. An SLO is your promise about that measurement, like “95% of our pizzas will arrive at least 150°F” or “99% of deliveries will be made within 30 minutes.”
The “error budget” is simply the small percentage of times you’re allowed to break that promise without feeling bad. If your SLO is 95% hot pizzas, your error budget is 5% of deliveries that can arrive colder. If you start delivering too many cold pizzas and use up that 5% budget, it’s a signal to stop adding new toppings (new features) and instead focus all your effort on fixing the ovens and improving delivery logistics (reliability work) until you’re back on track.
Why interviewers ask this
Interviewers ask this to gauge your understanding of fundamental SRE concepts, your ability to define measurable metrics for service health, and your awareness of the trade-offs between reliability and development speed. It shows if you think proactively about service quality.
What a strong answer signals
A strong answer signals deep knowledge of SRE philosophy, practical experience in defining and implementing SLIs/SLOs, and an understanding of how these concepts influence engineering priorities and communication with stakeholders. It highlights a proactive approach to reliability.
Common follow-ups
- How would you gather data for your chosen SLIs for a distributed system?
- Describe a situation where an SLO was consistently missed, and how your team responded to address it.
- What are the challenges in defining meaningful SLOs for a brand-new service with no historical data?
Advanced variation
Design SLIs and SLOs for a complex asynchronous workflow involving multiple microservices, external third-party APIs, and eventual consistency. How would you account for cascading failures and dependency SLOs, and what would your composite error budget strategy be?
Consider an e-commerce checkout service. Before implementing SLIs/SLOs, the team might react to vague customer complaints about “slow checkouts,” leading to reactive firefighting. After defining SLIs like “checkout latency” (measuring P99 response time) and “checkout error rate” (HTTP 5xx responses), with SLOs set at “P99 latency under 500ms for 99.9% of requests” and “error rate under 0.1% over 7 days,” the team can now proactively monitor these metrics. This allows them to quickly identify when performance degrades below acceptable thresholds, triggering alerts and guiding remediation efforts based on data, rather than waiting for customer complaints or subjective feedback.
- 1Service Level Indicators (SLIs) are quantifiable metrics measuring service health from a user’s perspective.
- 2Service Level Objectives (SLOs) are specific target values set for chosen SLIs, defining acceptable reliability levels.
- 3The error budget is derived from the SLO and represents the permissible amount of service unreliability over a period.
- 4Depleting the error budget signals a critical need to prioritize reliability work over new feature development.
- 5Effective SLI and SLO definition requires collaboration with business stakeholders and focus on user experience.