Service Level Objective (SLO)

What is a service level objective (SLO)?

A service level objective, or SLO, is an internal target for how reliable a service has to be, written as a number you can measure. Not "the sales pipeline should be reliable", but "99.5 percent of daily loads finish before 07:00, measured each month".

An SLO always has three parts: a metric, a target, and a time window. The metric is what you measure, the target is the line it has to stay on, and the window is the period you judge it over, usually four weeks or a calendar month.

The idea comes from site reliability engineering, where teams at Google set SLOs to argue about reliability with numbers instead of opinions. It carries over to data work: everyone agrees a pipeline or report should be up to date and correct, but nobody has written down what that means.

SLI, SLO and SLA: how the three differ

These three get mixed up constantly, and telling them apart is the point.

• SLI is the measurement. A service level indicator describes one aspect of the service as a number, usually good events divided by total events. "Percentage of daily loads that finished before 07:00" is an SLI.

• SLO is the internal target for that measurement. "That percentage should stay at or above 99.5 over a month" is an SLO. You set it yourself, and missing it is a signal to your own team.

• SLA is the external contract. A service level agreement promises a number to a customer and carries consequences when you miss it: a refund, a credit, or a penalty.

The clean test comes from the SRE literature: ask what happens if the target is missed. A financial or contractual consequence means an SLA. If the only consequence is that your team goes and fixes something, it is an SLO. You can run SLOs internally without ever signing an SLA. On a shared dataset, the SLA is often written into a data contract between the producing team and the consuming team.

The error budget

Once you have an SLO, the error budget comes with it. The error budget is 100 percent minus the SLO. A 99.5 percent target means you accept 0.5 percent failure over the window. A 99.9 percent availability objective over three million requests in four weeks leaves room for three thousand failed requests.

Treat the budget as a spending account rather than a scoreboard. While budget is left, the team can ship changes and take on reasonable risk, because the occasional failure is already paid for. When it runs out, new features wait and the next work is whatever makes the service stable again. That one rule keeps "move fast" and "keep it reliable" from becoming a standing argument.

It also explains why 100 percent is the wrong target. A 100 percent target leaves zero budget, so every change becomes a risk you cannot afford and delivery slows to a crawl. Each extra nine costs sharply more while users barely notice: a 99.9 percent availability target allows about 43 minutes of downtime a month, and 99.99 percent cuts that to roughly 4 minutes. Set the target at the lowest level your consumers accept.

SLOs for a data product

On a data product, the three objectives worth writing down are usually freshness, completeness, and availability.

• Freshness. A ceiling on how old the data may be. "The sales table is loaded before 07:00 on 99.5 percent of working days." This is the expectation a data SLA on data freshness makes explicit, and the one that data downtime breaks first.

• Completeness. A floor on how much of the data is present. "Fewer than 0.1 percent of customer records are missing a customer number." A data quality rule expressed as a number.

• Availability. Whether consumers can reach the data when they need it. "The semantic model answers queries successfully 99.9 percent of the time during business hours."

Freshness is also one of the core signals in data observability, which is usually where these numbers get measured. A good SLO gives each dataset an owner, a threshold, and the moment a quiet problem turns into a real one.

A worked freshness example

Take the freshness objective above: 99.5 percent of daily loads finish before 07:00, judged over a month.

A 30-day month has 30 loads. The error budget is 0.5 percent of 30, which is 0.15 loads, less than one. So a single late morning, one load in thirty, is 3.3 percent failure and breaks a 99.5 percent monthly target on its own.

Widen the window and the number gets more workable. Across a year of 365 daily loads, 0.5 percent is about 1.8 loads, so the same target allows fewer than two late mornings all year. The percentage means little without the event count behind it: on a low-frequency job, a high target is a zero-miss target in disguise.

What to watch out for with SLOs

• Agree them with the people who use the data. An SLO that a data consumer never signed off on protects the wrong thing. Set the target against what actually hurts when the data is late or wrong.

• An SLO without an SLI is a wish. If you cannot measure the indicator automatically, you have a hope, not an objective. Keep the set small; a handful of indicators per data product is plenty.

• Write down what happens when the budget is gone. A runbook that names the response, who gets paged and what gets frozen, is what makes an SLO change behaviour rather than sit in a wiki.

• Keep SLOs apart from recovery targets. How much downtime you tolerate is an SLO question. How fast you must recover and how much data you can lose in a disaster are recovery targets, RTO and RPO, and they belong to your disaster recovery plan.