Defining SLIs and an SLO for an auth service?

WHAT THIS TESTS Whether you can ground reliability in what users actually experience, choose measurable indicators, and set a target that is meaningful and achievable rather than aspirational guesswork.

A GOOD ANSWER COVERS Start from the critical user journeys of an auth service: logging in and validating tokens. Define SLIs as the ratio of good events to valid events. An availability SLI is successful auth requests over total valid requests, where success excludes server-side 5xx and timeouts but counts legitimate credential rejections as the service working, not failing. A latency SLI is the fraction of auth requests served faster than a threshold, for example token validation under 100ms, since slow auth blocks every downstream action. Choose the measurement point users feel, typically the server or load-balancer edge. Then propose an SLO: a target value over a defined rolling window, such as 99.95 percent availability over 28 days, justified by user expectations, the criticality of auth as a dependency for everything else, and historical performance. Leave headroom so the gap to 100 percent forms a usable error budget. Distinguish the internal SLO from any external SLA, which carries contractual penalties and is usually looser.

COMMON WRONG ANSWERS Using infrastructure metrics like CPU or memory as SLIs, which do not reflect user experience. Picking five nines arbitrarily without cost or need justification. Counting valid credential rejections as failures. Omitting the time window, making the SLO unmeasurable. Conflating SLO with SLA.

LIKELY FOLLOW-UPS Why is latency especially critical for auth. How do you pick the target number. What is the difference between SLO and SLA. How does this feed an error budget.

ONE CONCRETE EXAMPLE For the auth service you define two SLIs: availability as non-5xx login responses over valid login attempts, and latency as the fraction of token validations under 100ms. Measured at the edge, recent data shows about 99.97 percent availability. You propose an SLO of 99.95 percent availability and 99 percent of validations under 100ms over a rolling 28 days. The small gap to perfection becomes the error budget that governs how aggressively the team can ship changes.