What is an SLO and how do you define API availability?

WHAT THIS TESTS Whether you can move from a fuzzy reliability ambition to a number that is measurable, agreed upon, and tied to user experience.

A GOOD ANSWER COVERS An SLI is a quantitative measure of service health, such as the fraction of successful requests. An SLO is the target you commit to for that SLI over a defined window, for example 99.9 percent successful over a rolling 28 days. For a stateless web API, define the availability SLI as good requests divided by valid requests. Good usually means responses that are not 5xx and that complete under a latency threshold, while you exclude or carefully classify 4xx because client errors are not the service failing. State the measurement boundary explicitly, preferring the load balancer or server edge so you capture what users actually experience.

COMMON WRONG ANSWERS Defining availability as uptime from an external pinger, which misses partial failures and slow responses. Counting all 4xx as failures, which penalizes the service for client mistakes. Picking a number like five nines with no error budget reasoning or cost justification. Forgetting to specify the time window, which makes the SLO unenforceable.

LIKELY FOLLOW-UPS How do you handle latency in the same SLO. Where do you measure, client or server. How does this SLO feed an error budget. What window length and why rolling versus calendar.

ONE CONCRETE EXAMPLE You set the API at 99.9 percent over 28 rolling days. The load balancer emits a counter of responses by status class and a latency histogram. Each minute you compute good requests, meaning non 5xx responses under 300ms, over total valid requests. Summed across the window, that ratio is your achieved SLI, and any shortfall against 99.9 percent burns the error budget that gates risky releases.