We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Observability Monitoring
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Observability Monitoring
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Ask five engineers "is the service healthy?" and you'll get five different answers. One checks if the homepage loads. Another checks error rates. A third pings the health endpoint. The database admin checks query times. The product manager looks at user complaints.
They're all measuring different things, and none of them has the complete picture. "The service is working" is too vague to be useful. You need specific, measurable quantities that objectively describe how well the service is performing from the user's perspective.
That's what Service Level Indicators (SLIs) are: the specific metrics you measure to determine service health. Not "is it working?" but "what percentage of requests returned a successful response in under 300ms over the last 5 minutes?" One is a feeling. The other is a number you can track, alert on, and report to stakeholders.
Google's SRE handbook identifies four primary SLI categories:
| SLI Type | What It Measures | Formula | Example |
|---|---|---|---|
| Availability | Can users reach the service? | Successful requests / Total requests | 99.95% of requests returned non-5xx |
| How fast does it respond? | Requests below threshold / Total requests | 95% of requests completed in < 200ms | |
| How much can it handle? | Requests processed per second | Sustains 10,000 requests/second | |
| Correctness | Does it return the right answer? | Correct responses / Total responses | 99.999% of calculations are accurate |
The most common SLIs for web services are availability and latency. Most users don't care about throughput directly, they care that their request succeeds (availability) and completes quickly (latency).
Key principle: SLIs should measure the user's experience, not the system's internals. "CPU utilization is 45%" is a system metric, not an SLI. "99.9% of API requests succeed" is an SLI because it describes what the user observes.
Where to measure: Ideally, measure at the boundary closest to the user. Measuring latency at the captures the full request lifecycle. Measuring at the application server misses network transit time and load balancer overhead.