SLI (Service Level Indicator)

An SLI — service level indicator — is a measurable aspect of service behavior that reflects the user experience. Common SLIs include availability (successful requests ÷ total requests), latency (request duration at a percentile), and correctness (absence of data errors).

SLIs are the raw signal. SLOs set targets on top of them. Alerts and dashboards should ultimately trace back to SLIs — otherwise you risk paging on infrastructure trivia while customers suffer silently.

Why it matters

Incident severity, customer communication, and reliability investments all improve when everyone agrees what “broken” means. SLIs anchor that definition in data instead of opinion. They also shorten MTTD: when monitors track what users care about, detection aligns with real impact, which is a core theme in our What Is Incident Management? guide.

Example

For a checkout API, you might track:

• Availability SLI — non-5xx responses ÷ total responses
• Latency SLI — percentage of requests completing under 300ms
• Freshness SLI — percentage of reads returning data newer than five minutes

An incident might breach the latency SLI while availability still looks fine — a pattern worth a lower severity but still customer-visible.

Common mistakes

• Too many SLIs — pick a small set per service; everything cannot be critical.
• Measuring the easy thing — server uptime instead of successful end-to-end transactions.
• Ignoring the denominator — error rates without traffic context mislead during low-volume periods.
• SLIs that never connect to paging — indicators without alert paths do not improve detection.

Define SLIs with product and support input, then wire them to escalation policies and status page updates when user-visible thresholds break. Recovery speed (MTTR) only matters once your SLIs tell you something is wrong.