SLIs, SLOs, SLAs, and Error Budgets Questions
Defining and operating reliability targets. Covers choosing service level indicators, setting service level objectives and agreements, computing and spending error budgets, and using them to drive engineering decisions. Includes negotiating reliability targets with stakeholders.
Define and implement SLOs, error budgets, and escalation policies for a data-serving API used by analysts. Include measurable SLIs, how to calculate burn rate, on-call actions when error budget is consumed, and how engineering time should be allocated against the error budget.
Sample Answer
A data-serving API for analysts needs SLOs and an error-budget policy structured the same way a request-serving API's would be, with the escalation and staffing allocation explicitly tuned to an analyst audience's actual usage pattern (often bursty, batch-style queries) rather than assumed to be identical to a typical low-latency consumer API.
Structured elaboration
SLIs: query success rate, p95/p99 query latency (with an explicit acknowledgment that analyst queries have a much wider natural latency distribution than a typical API, since some are trivial lookups and others are large aggregations), and data freshness (how current the underlying data is). Burn rate calculation follows the standard formula, (1−observed SLI)/(1−SLO), computed per SLI. Escalation: on-call actions when budget is consumed should be graduated (a warning-tier notification for moderate burn, requiring investigation but no immediate action; a page for severe or fast burn) with clear ownership (which on-call rotation is responsible for a query-latency regression versus a freshness regression, since these may trace back to different root causes and even different teams). Engineering time allocation: a documented policy for how much of the team's capacity gets reallocated to reliability work as budget burns (e.g. at 50% budget consumed for the month, a fixed percentage of the next sprint shifts to reliability fixes; at full exhaustion, feature work pauses entirely until the budget position recovers).
Worked example
SLO: 99.9% query success over 30 days, p95 latency < 2s (chosen deliberately looser than a typical low-latency API's, reflecting that analysts tolerate longer queries in exchange for richer analytical capability), freshness < 15 minutes. At 50% budget consumed mid-month, the policy allocates 20% of the next sprint to reliability work; at full exhaustion, all new analyst-facing feature work pauses until the team demonstrably stabilizes the underlying issue and the budget position recovers.
Trade-offs and pitfalls
The biggest mismatch risk is copying a typical low-latency API's percentile targets onto an analyst-facing service without adjusting for its genuinely different, often bimodal latency distribution (trivial lookups versus heavy aggregations); a single p95 target across both query shapes can be dominated by whichever type happens to be more common that period, obscuring a real regression in the less-common but still important query type. It's also worth deciding explicitly whether freshness and query-latency degradations should share the SAME error budget or have separate ones, since they often have different root causes and different appropriate engineering responses, and lumping them together can mask which specific problem is actually driving the burn.
Design SLOs for an e-commerce checkout service that depends on payment gateway, inventory, and search systems. Explain which SLOs map to business KPIs (e.g., conversion rate), which are service-level, how to handle downstream failures, and how to surface these SLOs in dashboards for product and engineering stakeholders.
Sample Answer
A checkout service's SLOs need to separate what's genuinely SYSTEM-level (is the service itself healthy) from what's USER-IMPACTING (did the customer actually get to complete their purchase), because the two can diverge when a downstream dependency fails gracefully versus catastrophically.
Structured elaboration
Business-KPI-mapped SLO: checkout completion rate, directly tied to conversion rate, the number product and leadership actually care about; this should reflect the FULL user journey, including downstream calls to payment gateway, inventory, and search. Service-level SLOs: each downstream dependency (payment gateway latency/error rate, inventory-check latency, search-availability) gets its own SLO so a specific failing component can be identified quickly, distinct from the aggregate customer-facing number. Handling downstream failures: define explicit fallback behavior (e.g. if inventory-check times out, default to "assume available, reconcile after" rather than blocking checkout entirely) and make sure the aggregate checkout SLO reflects the ACTUAL user outcome after fallback, not a naive AND of every dependency's individual health.
Worked example
Three concrete SLIs balanced together: checkout success rate (99.9% target, the primary business-facing SLI), checkout latency (p95 < 2s end-to-end), and payment-gateway error rate specifically (< 0.1%, tracked separately since it's the dependency most likely to cause a user-impacting failure even when the checkout service's own code is healthy). Dashboards for engineering show all three plus each downstream dependency's own health; the dashboard shown to product and executives shows primarily the business-facing checkout success rate and conversion-rate correlation, with the ability to drill down into the technical SLIs only if something looks wrong, since flooding an executive dashboard with every service-level SLI obscures the one number that actually matters to them.
Trade-offs and pitfalls
A common mistake is defining the checkout SLO as a strict AND across every downstream dependency's own SLO (checkout is "up" only if payment gateway, inventory, and search are ALL simultaneously healthy), which massively UNDERSTATES real checkout availability if the service has reasonable fallback behavior for a degraded dependency; the checkout SLO should reflect actual USER outcomes after fallback logic runs, not a naive composition of dependency health. It's equally a mistake to surface every technical service-level SLI to executive stakeholders undifferentiated from the business-facing number; the audience-appropriate layering (business KPI first, technical detail on demand) is itself part of designing this SLO set well, not an afterthought.
Propose a measurable Service-Level Objective (SLO) related to code quality for a public API (e.g., regression-caused errors per 1K requests). Explain how you'd instrument the SLO, what data sources you'd use, how to alert on breaches, and what operational playbooks you'd trigger.
Sample Answer
Code quality is usually tracked informally (code review comments, static-analysis scores), but turning "regressions caused by recent code changes" into an actual SLO forces the same operational discipline onto it that latency and availability already get.
Structured elaboration
A concrete SLO: "no more than 2 regression-caused errors per 1,000 requests, attributable to a change deployed within the last 7 days, measured over a rolling 30-day window." Instrumentation: every error needs to be tagged, at the point it's logged, with whether it correlates to a recent deploy (via a deploy-timestamp lookup against the error's occurrence time and a code-ownership/blame mapping), distinguishing a "regression" (newly introduced) from a long-standing, pre-existing bug (which is a different, separate reliability problem, not a code-quality-regression one). Data sources: deploy-event logs (timestamped, tied to a specific commit/PR), error-tracking system output (with stack traces mapped back to the responsible code area), and a code-ownership mapping (so a regression can be attributed to a specific team or even a specific recent PR).
Worked example
Alerting: if the rolling regression-error rate crosses the 2-per-1000 threshold, the alert should include the SPECIFIC recent deploys that correlate with the spike (not just "regressions are up"), since actionable remediation depends on knowing which change to investigate first. Operational playbook triggered: first, confirm the correlated deploy via the error-tracking system's stack traces; second, if confirmed, roll back that specific deploy (not the whole service) if the fix isn't trivial and fast; third, require the offending PR's original author (or team) to add a regression test covering the specific failure before the fix is re-attempted, closing the loop so the same class of regression doesn't recur silently.
Trade-offs and pitfalls
Attribution accuracy is the hardest part of this SLO to get right: a naive "any error within N days of any deploy" heuristic will over-attribute unrelated errors to recent deploys purely by coincidental timing, so the attribution logic needs real evidence (a stack trace pointing into recently-changed code, not just temporal proximity) before counting an error as a genuine regression. It's also worth deciding whether this SLO should apply uniformly to every code change or be weighted by the CHANGE's actual risk profile (a large refactor plausibly deserves closer regression scrutiny than a one-line config tweak), similar to the release-risk-scoring discussion elsewhere, rather than treating every deploy as an equally likely source of regression.
Describe how you would determine SLAs, SLOs, and SLIs for a new customer-facing microservice. Which stakeholders would you involve, what candidate SLIs would you propose, how would you pick SLO targets and error budgets, and what process would you use to validate them after launch?
Sample Answer
For a brand-new customer-facing microservice, the process matters as much as the numbers: getting the right stakeholders in the room before committing to a target avoids the two most common failure modes of setting a target that nobody can actually deliver, or one that nobody actually needed.
Structured elaboration
Stakeholders to involve: the engineering team building the service (technical feasibility), product/business (what does the user-facing experience actually require, tying back to a real business goal), and whoever owns any existing customer-facing SLA the new service might roll up into. Candidate SLIs should be proposed from the golden-signals framework (latency, traffic, errors, saturation) adapted to this specific service's actual failure modes, not copied wholesale from an unrelated service. SLO targets and error budgets should start deliberately conservative given no historical telemetry (see the bootstrap-a-new-service discussion), and the validation process after launch should include a defined observation period (2-4 weeks of real traffic) before the initial target is either confirmed or tightened.
Worked example
For a new "order-status" microservice: stakeholders are the owning team, the product manager who defined the "customers should see accurate order status within seconds" requirement, and the platform team whose existing customer SLA this service's reliability rolls up into. Candidate SLIs: request success rate and p95 latency, both instrumented from day one with no enforced target initially. After a 3-week observation period showing p95 stabilizing around 120ms and 99.8% success, the team sets the actual SLO at p95 < 200ms / 99.7% success, both with real headroom below observed performance, and documents the validation process (what was observed, what target was chosen and why) so the decision is auditable later.
Trade-offs and pitfalls
Skipping the stakeholder step and letting engineering set the target unilaterally often produces a technically-reasonable but business-irrelevant number (precisely calibrated to what's easy to achieve, not to what users or the business actually need); skipping the observation period and committing to a target immediately at launch, as covered elsewhere, risks locking in a target the service can't yet sustain. It's worth being explicit, in writing, about the SLO's provisional status during the observation period, so nobody downstream treats the placeholder number as a final commitment before it actually is one.
What is an 'error budget policy'? Give two concrete, real-world examples of policies (one automated and one manual) describing thresholds, actors, and actions. Explain why each example helps balance velocity with reliability.
Sample Answer
An error budget policy is the pre-agreed set of rules for what actually happens once budget consumption crosses specific thresholds, turning "we have an error budget" from an abstract concept into concrete, predictable action.
Structured elaboration
A good policy names the threshold, who is notified or empowered to act, and exactly what they do or are authorized to do; it needs both an AUTOMATED tier (fast, mechanical, no human judgment required) and a MANUAL tier (requires a person to weigh context, because the automated response alone isn't sufficient at that severity). Automated example: for a 99.9%-SLO service, if more than 50% of the WEEKLY error budget allocation is consumed, the CI/CD pipeline automatically restricts merges to hotfix-only, no human approval needed to trigger this, though an override exists for genuine emergencies. Manual example: if the error budget is fully exhausted for an entire QUARTER (a sustained, structural reliability problem rather than a one-off incident), engineering leadership and the product owner hold a joint review to reallocate the next quarter's roadmap toward reliability work, since the situation has moved from a tactical release-freeze to a strategic resourcing decision.
Worked example
Applying this to a data-engineering ingestion team illustrates the same mechanism in a different domain: an ingestion pipeline with a 99.9% freshness SLO uses its error budget the same way a request-serving API would, to decide the trade-off between shipping new pipeline features and investing in reliability fixes; when the pipeline's budget burns past the weekly threshold, new feature work pauses automatically (via the same CI gate pattern) in favor of fixing the freshness regression first, and if the budget stays exhausted across a full quarter, the team's roadmap gets the same leadership-level reallocation review as any other service.
Trade-offs and pitfalls
A policy that only defines automated actions without a manual, strategic tier will keep re-triggering the same tactical response (freeze, unfreeze, freeze again) without ever addressing a structural reliability problem; conversely a policy with only manual review and no automated tier is too slow to prevent damage during an active incident. The two tiers are solving different problems (fast tactical response vs slow structural correction) and a mature policy needs both, explicitly distinguished by which threshold triggers which.
Unlock Full Question Bank
Get access to all SLIs, SLOs, SLAs, and Error Budgets interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.