01 · Definition
What is a service level indicator (SLI)?
A service level indicator (SLI) is a carefully defined, quantitative measure of one aspect of the service your users receive. It is almost always written as a ratio — good events divided by valid events over a window — so it reads as a percentage where 100 is perfect. Typical examples are the share of message sends that succeed, the share answered within one second, or the share of inbound webhooks acknowledged with HTTP 200.
Every SLI needs three precise definitions: what counts as an event, what makes an event valid and what makes it good. For a WhatsApp send API you might count every POST to your send endpoint as an event, exclude as invalid the requests rejected for the caller's own mistakes (a malformed number, missing template parameters), and count as good only those that returned a wamid within one second. Change any of the three and you have a different SLI.
An SLI is not a target. It is the measurement that a service level objective (SLO) sets a target on — 'send SLI at least 99.5% over 28 days' — and the error budget is the room between the two. Common SLI families are availability (did it succeed), latency (was it fast enough), freshness (how old is the data), correctness and, for pipelines, throughput. The four golden signals — latency, traffic, errors and saturation — are a good place to hunt for candidates, though usually only latency and errors become SLIs; traffic and saturation explain why they moved.
Key takeaways
- A service level indicator (SLI) is a measured ratio: good events divided by valid events, shown as a percentage over a time window.
- The SLI is the measurement; the SLO is the target set on it, such as 99.5% over 28 days.
- Good SLIs measure what users feel — a send returning a
wamidwithin one second — not server CPU or memory. - Define 'valid' carefully: exclude requests that failed through the caller's own mistake, or the ratio stops measuring your reliability.
- Measure as close to the user as you reliably can: at the load balancer or with a probe, not only inside the service.
02 · Specifications
A service level indicator (SLI): key facts and limits
| Formula | SLI = good events ÷ valid events × 100% |
|---|---|
| Common windows | Minutes for alerts; 28 or 30 days for SLOs |
| SLI families | Availability, latency, freshness, correctness, throughput |
| Send SLI example | wamid returned within 1,000 ms |
| Webhook SLI example | Events acknowledged with HTTP 200 |
| Not an SLI | CPU, memory, queue length (causes, not outcomes) |
03 · Operation
How does a service level indicator (SLI) work?
Start from a user journey
Pick a journey that matters — a login OTP, an order update, an inbound chat reaching an agent — and ask which failure or slowness the user would actually notice.
Define event, valid and good
Write it down precisely: 'POSTs to /send; valid = all except 4xx caused by bad input; good = returned a
wamidwithin 1,000 ms'. Ambiguity here becomes arguments later.Choose where to measure
Application logs are easy but miss requests that never reached you; load-balancer metrics see more; synthetic monitoring probes and client telemetry see the most. Pick the closest point you can measure reliably.
Compute the ratio over windows
Count good and valid events from structured logging output or metrics, divide, and report over rolling windows — minutes for alerting, 28 or 30 days for the SLO.
Check it against reality
Confirm that dips in the SLI line up with real incidents and customer complaints. If users suffered while the SLI stayed green, the definition measures the wrong thing.
04 · Code samples
A service level indicator (SLI) in code
-- Latency-qualified send SLI over the last 28 daysSELECTCOUNT(*) FILTER (WHERE http_status < 400 AND wamid IS NOT NULL AND duration_ms <= 1000)::numeric/ NULLIF(COUNT(*) FILTER (WHERE NOT caller_error), 0) * 100 AS send_sli_percentFROM whatsapp_send_logWHERE created_at >= now() - interval '28 days';
Good events are a subset of valid ones; requests the caller got wrong are excluded from the denominator, not counted as bad.
05Playground
A working model of SLI. Use its controls to replay it step by step.
Slide the counts: what is this month's SLI?
The formula
Good events (wamid within 1 s)9,96,800divided byValid events (caller errors excluded)10,00,000equalsSend SLI99.68%
Send SLI
99.68%
Shown as a percentage (the ratio × 100).
Working
- 9,96,800divided by10,00,000equals0.9968→ 99.68%
Illustrative 28-day counts. The ranges keep good events at or below valid events, as they always are. Compare the result with an SLO of 99.5%.
Send SLI = 99.68%.
06 · Worked example: An OTP SLI for a Chennai lender
Example: An OTP SLI for a Chennai lender
A lending app in Chennai defines its login SLI: valid events are OTP send requests from its own login service; good events are those for which the Cloud API returned a wamid within two seconds and a sent status webhook arrived within thirty seconds. In September it logged 1,240,000 valid requests and 1,233,800 good ones, an SLI of exactly 99.50%. When the figure dipped to 98.9% one week, the cause turned out to be a slow DNS resolver in one availability zone — invisible on CPU graphs, obvious in the SLI.
07 · Rationale
Why does a service level indicator (SLI) matter?
Without an SLI, 'is the WhatsApp integration healthy?' gets answered by gut feel or by whichever dashboard is loudest. A well-chosen SLI turns the question into one number that tracks what customers experience: OTPs going out, order updates sent, inbound chats reaching agents. It lets developers and business owners agree on what 'good' means, reveals slow decline before it becomes an outage, and supplies the data for deciding whether to ship features or fix reliability.
08 · Cautions
Common mistakes with a service level indicator (SLI)
Measuring machines instead of users
CPU, memory and pod restarts help with diagnosis but say little about whether OTPs went out. Build SLIs from request outcomes and latency.
Counting callers' mistakes as your failures
If invalid numbers or missing parameters count as bad events, one buggy caller can sink the SLI. Exclude them from valid events and alert on them separately.
Averages instead of thresholds
Average latency hides the slow tail, and even P99 latency is a single number rather than a ratio. A latency SLI should be the share of requests faster than a threshold, which counts exactly the users who waited.
Too many SLIs
Twenty indicators nobody reads are worse than three everyone trusts. Start with one or two per critical journey.
Measuring only inside the service
Requests that time out at a proxy or never reach your pods never appear in application logs. Add a measurement point closer to the user, such as the load balancer or a synthetic probe.
09 · Recommended practice
Best practices for a service level indicator (SLI)
- Write each SLI as a sentence a non-engineer understands, then as a query.
- Build SLIs from the same structured-log fields you debug with, so a dip leads straight to example requests.
- Keep separate SLIs for OTP, utility and marketing traffic when their expectations differ.
- Store the raw good and valid counts, not only the percentage, so any window can be recomputed.
10 · Questions and answers
SLI FAQs
- What is the difference between an SLI and an SLO?
- An SLI is the measurement; an SLO is the target set on it. 'Share of sends returning a wamid within one second' is an SLI; 'that share stays at or above 99.5% over 28 days' is the SLO.
- What are examples of SLIs for an API?
- Availability (share of valid requests that succeed), latency (share served faster than a threshold) and, for messaging, end-to-end delivery time. For a WhatsApp integration, sends returning a
wamidquickly and webhooks acknowledged with 200 are good starting points. - Should 4xx errors count against an SLI?
- Usually not when the caller caused them, such as validation errors. Exclude those from valid events, but count errors your own system caused — a misconfigured token, an over-tight rate limit — as bad events.
- How do you calculate an SLI?
- Divide good events by valid events over a window and multiply by 100. For example, 1,233,800 good sends out of 1,240,000 valid ones gives an SLI of 99.50%.