Service-Level Indicators and Objectives
Service-level indicators measure whether users receive an acceptable service outcome. Service-level objectives set the target for those measurements, so teams can decide when reliability work or release risk needs attention.
itPlatform engineering and SRE | OpenSkills.info
Intro
Service-Level Indicators and Objectives
A service-level indicator, or SLI, measures a service behavior that matters to users. A service-level objective, or SLO, states the target for that measurement over a defined period. Together, they turn a statement such as “the service should be reliable” into a measurable agreement.
The useful sequence is:
user journey → service outcome → SLI → SLO → error budget → decision
You start with the user’s outcome, not the metric that happens to be available. For an API, a useful outcome might be receiving a successful response within a latency threshold. For a data pipeline, it might be receiving correct, fresh data by a deadline. The measurement is a proxy for that outcome, so its limits need to be explicit.
Separate the indicator from the objective
An SLI is the measured value. For a request-driven service, a common form is a ratio of good events to total eligible events:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://sre.google/sre-book/service-level-objectives/
Supports
- SLI and SLO definitions, conditions, and target selection
- User-centered indicator selection and limits of server-side and aggregate measurement
- Representative indicator families and distinctions from SLAs
- Quiz questions 1, 2, 4, 5, and 8
- First reference-link rationale
- https://sre.google/workbook/implementing-slos/
Supports
- SLI specification versus implementation and measurement tradeoffs
- Request, pipeline, and storage indicator examples
- Good and total events, error-budget calculation, stakeholder agreement, and policy actions
- Quiz questions 2, 3, 4, 6, and 8
- Second reference-link rationale
- https://sre.google/workbook/alerting-on-slos/
Supports
- Error budgets, burn rate, alert precision, and multiwindow alert design
- Quiz question 7 and the third reference-link rationale
- https://cloud.google.com/blog/products/devops-sre/availability-part-deux-cre-life-lessons
Supports
- Practical distinctions between SLIs, SLOs, and SLAs
- Reliability targets, user expectations, and business tradeoffs
- Fourth reference-link rationale
- https://github.com/dastergon/awesome-sre
Supports
- Discovery of the Service Level Agreement section and its SLO resources
- Selection of ecosystem links for SLO implementation and explanation
- https://mattermost.com/blog/sloth-for-slo-monitoring-and-alerting-with-prometheus/
Supports
- Mattermost SLI monitoring and SLO alerting case study
- Mattermost Awesome Link rationale