Service Health
What is an SLO?
A service level objective, or SLO, is a measurable target for how well a service should work. This guide explains the terms from scratch and how Service Health uses them.
Start with what the customer needs
“Checkout should be fast” is hard to check. “At least 99% of checkout calls should take no more than 500 milliseconds over the last 28 days” gives the team something it can measure.
That sentence has three parts:
- A measure: the share of calls that finish within the speed threshold.
- A target: at least 99%.
- A window: the last 28 days.
A millisecond is one thousandth of a second. A 500 ms threshold allows half a second for the measured call. It does not measure the whole experience of loading a page in a browser.
SLI, SLO and SLA
| Term | Meaning | Example |
|---|---|---|
| Service level indicator (SLI) | What you actually measured | 99.4% of calls took no more than 500 ms |
| Service level objective (SLO) | What you aim to achieve | At least 99% should take no more than 500 ms |
| Service level agreement (SLA) | An agreement with a customer, which may include consequences for missing it | A contract promising a level of availability |
Service Health evaluates your objectives. Its status does not establish whether you met a contractual SLA.
The app's two objectives
Speed
Speed is the share of calls that do not exceed the slow line, the duration beyond which a call counts as slow. The default line is 500 ms. The app counts calls over that line directly; it does not judge the objective by an average or by p95.
For example, 600 slow calls out of 100,000 means 99.4% were within the line. That meets a 99% speed objective.
Success
Success is the share of calls without a server error. HTTP 5xx responses, such as 500 or 503, spend this budget. HTTP 4xx responses, such as 401 or 404, do not count as server errors in this objective.
For OpenObserve, a server span with no HTTP status also counts as a server error when its span status is ERROR. This lets a recorded failure count even when no HTTP response code is present.
This distinction matters: a healthy success objective does not prove there are no customer problems. Unexpected 4xx responses may still deserve investigation.
Speed and success are separate. A fast error can spend the success budget; a slow successful call can spend the speed budget; one call can spend both.
What does a rolling window mean?
The app normally looks back 28 days. As time passes, older calls leave the window and newer calls enter it. There is no monthly reset. Admins can choose 7, 28 or 30 days for each tier.
An outage can continue affecting the objective after it is fixed, until the bad calls leave the window or enough good calls change the share. Error budgets explains how to read this alongside recent burn.
Which target should we choose?
A higher percentage gives the team less room for slow calls or errors. Moving from 99% to 99.9% reduces the allowance from one call in 100 to one in 1,000.
Start with a target tied to what users need, then check whether your measurements represent that experience. A checkout API and a background process need different treatment. Service Health provides tiers and strictness presets as starting points, with overrides and inheritance for deliberate exceptions.
Google's Implementing SLOs recommends agreeing on objectives with the people responsible for the product and service, using budgets to prioritise work, and revisiting the choices. Treat the initial target as a decision to review as you learn.
Streams, long-lived connections and recognised queue or job work are held to success only. Their long duration does not automatically make them slow request APIs. See Endpoints and exclusions.