SLA, SLO, and SLI connect user expectations with service measurements and commitments. Confusing them produces vague requirements such as “our SLA is 500 milliseconds,” without specifying the operation, request percentage, or period covered.
QA should distinguish what is measured, the team's target, and the agreement's actual commitments. This enables testable criteria without presenting a short test as proof of monthly reliability.
SLI: an observable service characteristic
An SLI, or service level indicator, quantifies service quality. Examples include the proportion of eligible requests that succeed or messages processed within a specified time. It needs a precise formula and data source.
Define the denominator and what counts as good. HTTP 200 alone may still carry a business error. Timeouts should not disappear from statistics because the server never logged completion. Measurement location should represent the chosen aspect of user experience.
SLO: a target and window
An SLO, or service level objective, sets an SLI target: for example, at least 99.9% of eligible requests succeed over a rolling 30-day window. A separate latency objective might require at least 99% of successful requests to complete within 500 ms.
These statements use different event populations; record that distinction. Otherwise, excluding slow errors from response-time measurements may accidentally improve the indicator. Define an owner, calculation window, exceptions, and user meaning. “100% always” rarely helps choose an engineering action without a failure model.
SLA: the agreement's commitments
An SLA, or service level agreement, describes an agreed service level and its delivery terms. It may specify calculations, exclusions, support procedures, and consequences of violations. Its content comes from the agreement itself; the acronym alone implies no particular compensation or penalty.
QA uses approved terms as requirements and raises ambiguities with the agreement's owners, without inventing customer promises. Internal SLOs are often stricter than external commitments to provide headroom, but that is a team decision rather than a universal mathematical rule.
Why error budgets matter
An error budget is the allowed proportion or number of bad events under an SLO. At 99.9% over one million eligible requests, the budget is 1,000 failed requests. It expresses reliability discussions in the target's own units.
A time-based 99.9% SLO over exactly 30 days permits 43.2 minutes of unavailability. This cannot automatically be transferred to request-based SLOs: equal downtime affects different request counts at different traffic levels. Use the specified model and keep different indicators' budgets separate.
Selecting and checking data sources
Server metrics are convenient but may miss DNS failures, load-balancer failures, or a broken frontend. Synthetic checks observe an external path but cover only their scenarios and locations. Real client events offer another view and require collection-completeness checks.
Choose the source according to the goal. Report readiness means a correct file is available, beyond job acceptance. API observations at an ingress gateway plus result checks may suffice. QA should understand blind spots and reconcile event counts between layers in a controlled test.
Practical example: a catalog SLO
The team defines eligible catalog requests at the ingress gateway, with a correct successful response as good, a rolling 30-day window, and a 99.9% target. Intentionally invalid parameters are excluded by a preapproved rule, while technical errors and timeouts remain included.
The window contains 1,000,000 eligible requests and 1,200 bad events. SLI = 998,800 / 1,000,000 = 99.88%. The target is missed and the budget exceeded by 200 events. Good average latency does not change that. The SLA outcome requires separate evaluation if its scope, window, or exceptions differ.
How QA verifies the calculation
Create a controlled test set: 980 correct responses, 10 technical errors, 5 timeouts, and 5 requests explicitly excluded by the rule. Including timeouts gives a denominator of 995 and 980 good events, for an SLI of approximately 98.49%.
Compare raw logs and dashboard values. Check retries for double-counting, window boundaries, and recovery after delayed telemetry delivery. The measurable outcome is the expected formula result and consistent classification of every event type. Missing timeouts are a measurement defect even if the UI works.
What can be established before release
A load test checks agreed criteria for a particular profile and duration. It can expose SLO risks, but twenty stable minutes cannot establish a 30-day production target.
Before release, test measurement, errors, degradation, and alerts with controlled events. In operation, monitor the SLO window and budget consumption rate. Brief spikes and sustained degradation require different responses, so one static red line may be insufficient.
Key takeaways for QA
SLI defines the measurement, SLO the target, and SLA the agreement's terms. Verification requires a formula, event population, window, and data source. QA helps make the system trustworthy by checking both service behavior and calculation correctness while keeping test conclusions within their limits.