General Interview: How Do You Explain SLI, SLO, and SLA to a Non-Technical Stakeholder?

Prompt and scenario

A sales lead treats the 99.9% SLA in a contract as a promise that the product never fails and asks engineering to guarantee no degradation. Explain SLI, SLO, and SLA in plain language, how you choose the measures, how you correct the misunderstanding, and how the terms affect releases and customer communication.

What the interviewer is testing

• Whether you connect abstract reliability terms to user journeys and business commitments.
• Whether you distinguish an internal goal, an observed signal, and an external contract instead of treating a percentage as an absolute guarantee.
• Whether you can explain how an error budget supports release, pause, and risk trade-offs.
• Whether you adapt to the audience, confirm understanding, and leave an actionable next step.

Clarifying questions to ask first

1. Which service, user journey, time window, and availability definition does 99.9% cover, and are maintenance or third-party dependencies excluded?
2. Is the SLA a contractual commitment with credits, or a non-contract target in sales material?
3. Do we already have SLI data, SLO targets, an error budget, and customer-impact reports?
4. Is the concern breach risk, customer experience, release speed, or internal resource priority?

A 30-second answer

I would confirm the service scope and contract meaning of 99.9%, then use an on-time-flight analogy: an SLI is the result we measure, an SLO is the target the team aims to meet, and an SLA is a formal customer commitment with scope, exceptions, and often credits. 99.9% is not zero failure; it is an allowed failure budget within a defined window. I would translate the signal into user impact and remaining risk, explain how the budget informs release, slowdown, or pause, ask the listener to restate it, and agree on an owner and review time.

Deep dive

1. Start with a user journey, not an acronym

I would ask what task counts as usable service, such as signing in, placing an order, or reading a report. A server-side success rate can hide client timeouts or a failed critical flow, so the SLI should represent user-perceived availability, latency, or correctness where possible. Explain the task and impact first, then introduce the acronym.

2. Establish boundaries with three definitions

An SLI is a repeatable signal, such as the success rate of critical requests or the share under a latency threshold. An SLO is a target for that signal over a window, such as 99.9% over 30 days. An SLA is a formal commitment to a customer or partner that may define scope, exceptions, notice, and credits. The numbers can relate, but responsibility, evidence, and consequences differ.

3. Convert the percentage into an error budget

Within a fixed window, an error budget is roughly the allowed failure portion. For 99.9% over 30 days, the scale is about 43 minutes of unavailability; this is an illustrative magnitude and must follow the contract’s measurement method. While the budget is healthy, releases can proceed within risk limits. If burn accelerates or the budget is exhausted, pause high-risk changes and prioritize repair.

4. Explain that an SLA is not “never fail”

I would explain that a contract normally defines measurement, exclusions, scope, and credits; it does not promise every request succeeds forever. If sales needs external wording, align the SLO, SLA, status page, support flow, and incident-notice timing instead of substituting an internal target for a contractual promise. Legal, sales, and engineering should confirm exceptions together.

5. Connect reliability to release choices

Release review can use the error budget as a shared gate: release as planned while it is healthy; reduce batch size, observe longer, or pause when burn is abnormal; repair first when exhausted unless a documented exception is approved. Options should include user impact, revenue or commitment impact, recovery time, and rollback conditions so reliability is not a unilateral veto.

6. Confirm understanding and govern continuously

After the conversation, ask the listener to restate the three definitions and current risk in their own words, then record questions and commitments. Review whether the SLI still represents users, the SLO drives useful behavior, and the SLA matches the contract each window. If the metric diverges from experience, fix measurement before debating a higher percentage.

A complete strong answer

I would confirm the service, user journey, time window, and contract boundary behind 99.9%, then start with a user task. An SLI is an observable result, an SLO is the team target over a window, and an SLA is a formal customer commitment with scope, exceptions, and credits. I might use the roughly 43-minute scale for 30-day 99.9% as an example, while following the contract’s measurement. Release while the budget is healthy, slow or observe when burn is abnormal, and pause high-risk changes when exhausted unless a joint exception is approved. I would ask sales to restate the model, align status and support communications, and review whether the metrics truly represent users.

Common failure modes

• Treating SLI, SLO, and SLA as synonyms without explaining responsibility boundaries.
• Calling 99.9% a promise of no failure at any time while ignoring windows, scope, and exceptions.
• Looking only at server metrics without validating critical journeys and client experience.
• Mentioning error budgets without connecting them to release, pause, and exception decisions.
• Overloading the listener with acronyms without checking understanding or assigning an action.

Follow-ups and extensions

Follow-up 1: What if sales asks to put the internal SLO in the contract?

Confirm measurement, scope, exceptions, notice, and credits, then have legal, sales, support, and engineering assess cost and risk together. An internal target can inform a commitment, but contract definition and operational capacity still require validation.

Follow-up 2: How do you choose multiple SLIs?

Split availability, latency, correctness, or freshness by user journey so one average cannot hide a critical path. For each SLI, define data source, sampling, window, missing-data treatment, and resulting action.

Follow-up 3: What if the SLO is met but customers still complain?

Check whether the SLI measures the real task and whether it misses a region, tenant, client, or business-success condition. Correlate complaint samples with end-to-end signals, then add or replace an SLI and adjust the target.

Follow-up 4: How do error budgets relate to credits?

An error budget is an internal risk and release mechanism; credits are a contractual SLA consequence. They may use the same incident record but cannot replace each other. Calculate external credits from the contract and use the internal budget for engineering priority and change pace.