Translate user expectations into service level indicators based on good events, valid events, latency, correctness and other observable outcomes instead of infrastructure convenience metrics.
Carry the same user journey forward: customer → edge/API → checkout → payment. Reuse prior SLI/SLO, alert, incident and recovery decisions where relevant so this module adds evidence to one reliability system rather than starting from zero.
An SLI should represent whether an important user interaction succeeded, not simply whether a component was alive. Examples include successful checkout requests, timely search results or fresh data delivery.
Choose a small number of indicators that matter to users and that can be measured consistently.
Many request-based SLIs can be expressed as good events divided by valid events. “Good” must be explicit: correct status, bounded latency, valid content or another testable condition.
The denominator also matters. Health probes, bots or requests outside the supported contract may need to be excluded so the indicator measures the intended population.
An edge proxy, application, synthetic probe and client telemetry observe different parts of the user journey. Document where the SLI is measured and what failures it cannot see.
Prefer the closest practical approximation to user experience, then complement it when blind spots are important.
Do not use a blanket status < 500 rule without documenting what it means. Some 4xx responses represent invalid or out-of-contract requests and may be excluded from the valid-event denominator; they should still be monitored separately.
For an otherwise valid user request, server-side admission control such as 429 or load shedding such as 503 is a user-visible inability to complete the journey and normally counts as bad for an availability SLI unless the service contract explicitly defines a different population.
Average latency can hide a harmed tail. For interactive services, define good events using a latency threshold or inspect percentiles derived from an aggregatable histogram.
Not every service is request/response. A batch or data-product SLI can measure the proportion of expected jobs completed before a deadline, or the proportion of observations whose data age stays below a freshness threshold.
SLI = good requests / valid requests
= 9,950 / 10,000
= 99.5%Goal: Calculate availability and latency-goodness from a small request dataset.
cat > /tmp/requests.csv <<'EOF'
status,latency_ms,valid
200,110,yes
200,780,yes
400,40,no
429,35,yes
503,20,yes
200,140,yes
EOFpython3 - <<'PY2'
import csv
rows=list(csv.DictReader(open('/tmp/requests.csv')))
valid=[r for r in rows if r['valid']=='yes']
good=[r for r in valid if r['status']=='200' and int(r['latency_ms']) <= 300]
print('valid_events',len(valid))
print('good_events',len(good))
print('good_ratio',f'{len(good)/len(valid):.3f}')
print('bad_by_policy',[(r['status'],r['latency_ms']) for r in valid if r not in good])
PY2Write the contract explicitly: which requests are valid, which status/latency combinations are good, where the measurement is taken, and why valid 429/503 responses are treated as bad user outcomes in this checkout example.
A useful SLI is both technically computable and semantically tied to what users experience.
Start the local SRE lab and query request/error counters from Prometheus.
./ops/setup-sre-local-lab.shfor p in ok ok slow fail shed; do curl -s -o /dev/null http://127.0.0.1:8000/$p || true; donecurl -fsS http://127.0.0.1:9090/api/v1/query --get --data-urlencode 'query=1 - sre_demo:error_ratio:1m'curl -fsS http://127.0.0.1:9090/api/v1/query --get --data-urlencode 'query=histogram_quantile(0.95, sum by (le) (rate(sre_demo_request_duration_seconds_bucket{outcome=~"ok|slow"}[1m])))'Three concept checks plus one scenario check.
A quantitative measure of a defined aspect of service behaviour, such as the ratio of good requests to valid requests.
Because the population of valid events determines what user experience the indicator represents.
Because the SLI can define good events as successful responses that also complete within the user-relevant latency threshold.
The application-side SLI has a measurement blind spot; an edge or client-side signal is needed to represent the affected user journey.
Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.
Attempt the core lab and knowledge checks before marking the module complete.