SLI (service level indicator)
The measured reliability number behind an SLO, such as the percentage of valid requests that succeeded or finished fast enough.
See it
What it is
An SLI is the measurement used to judge reliability. For availability it might be good requests divided by valid requests; for latency, the share of valid requests completed under 500ms. The SLI is the observed number, such as 99.93%. The SLO is the target placed on it, such as at least 99.9% over a rolling 28 days.
Choose an SLI for each user journey that matters, measure it as close to the user as practical, and define good, bad, and excluded events before writing the query. Ratios are usually more honest than averages: '95% of requests under 500ms' keeps the slow tail visible, while a 120ms average can hide a miserable minority. Google SRE calls the written definition the SLI specification and the actual telemetry query the SLI implementation.
Gotcha: the denominator can make any SLI look healthier than reality. Dropping timeouts, cancelled requests, low-traffic periods, or regions with missing telemetry silently removes bad experiences from the score. Document exclusions, alert when the measurement itself disappears, and do not substitute an easy server metric for the experience users actually care about.
Ask AI for it
Implement Prometheus SLIs for this service with recording rules. Define availability as non-5xx requests divided by all valid requests from http_requests_total, and latency as requests completed within 500ms divided by all valid requests from http_request_duration_seconds_bucket and its count. Exclude only the health-check route and document that exclusion beside the query. Record 5-minute and 28-day ratios, split the dashboard by route template and region, compare each result with its SLO target, and alert separately if either source metric disappears so missing telemetry cannot look like perfect reliability.