SLI — Service Level Indicator#

What it is#

An SLI is simply a number your system is actively generating right now.

Not a target. Not a promise. Just a real measurement being produced by your system at this moment.

• P99 latency = 180ms → SLI
• 0.5% of requests are returning errors → SLI
• System was available 99.7% of the last 30 days → SLI
• 95% of DB queries completed under 50ms → SLI

What to measure — and what NOT to measure#

You don't measure everything. You pick the measurements that directly reflect whether your users are having a good experience.

Good SLIs: - Message delivery latency — users feel this directly - Error rate on the API — users see these failures - Availability — is the service up when users try to use it?

Bad SLIs: - CPU usage — a server can be at 90% CPU and users are perfectly fine - Memory usage — same problem, doesn't map to user experience - Number of database connections — internal plumbing, users don't feel this

Wait — what's the difference between P99 and an SLI?#

This is the most common confusion after learning percentiles.

P99 is a calculation method. SLI is a concept — what you decided to measure.

• The SLI is the what — what are we measuring?
• P99 is the how — how are we computing that measurement?

You decide to measure response time → that decision is your SLI. You choose to express it as P99 → that's the calculation method you picked.

The same SLI can be expressed multiple ways:

And not all SLIs use percentiles at all: - SLI = error rate → "0.5% of requests failed" — a ratio, no percentile involved - SLI = availability → "99.9% uptime this month" — a percentage, no percentile involved

SLIs are always ratios or percentiles — never raw counts#

❌ "500 errors happened today" — raw count, meaningless without context. 500 errors out of 100 requests is catastrophic. 500 errors out of 10 million requests is fine.

✅ "0.5% of requests returned errors" — a ratio, meaningful regardless of traffic volume

Common SLIs by system type#