What is a data SLA? SLA vs SLO vs SLI for data
A data SLA is an agreement between the team that produces a dataset and the people who rely on it, stating what they can expect, such as 'the revenue table is updated by 7am on 95 percent of days'. The SLI is the measurement behind it, usually freshness. The SLO is the target for that measurement. The SLA is the commitment, with consequences, built on the SLO. Most teams need the SLI and SLO long before a formal SLA.
Three terms, three jobs
The vocabulary comes from operating services. Applied to data it stays useful if you keep the three apart.
- SLI (indicator). A measured number. “The load finished at 05:40.”
- SLO (objective). A target for that number over a window. “Finished before 07:00 on at least 95 percent of days over 30 days.”
- SLA (agreement). The promise to a consumer, referencing the SLO, often with a stated consequence such as a notification, a credit or a postmortem.
The order matters. You cannot hold an SLO without an SLI, and a promise without an SLO is a wish.
Freshness is the usual SLI
Consumers describe their needs as deadlines: the finance dashboard must be right when the team arrives, the export must be in the partner’s bucket by 9. That is a freshness requirement, and data freshness is cheap to measure. Volume and validity checks usually become additional SLIs once freshness is covered.
Note the difference from a plain freshness alert. An alert asks “is it late right now”. An SLI asks “how often has it been late”, which is the number you need to judge whether a promise is realistic.
Measure the SLI
Assume a loads table with one row per day and the time the load finished. This counts how many of the last 30 days finished before 07:00 and returns a row only when the rate is under the 95 percent objective.
SELECT count(*) AS days,
count(*) FILTER (WHERE loaded_at < day + interval '7 hours') AS on_time,
round(100.0 * count(*) FILTER (WHERE loaded_at < day + interval '7 hours')
/ count(*), 1) AS sli_pct
FROM loads
WHERE day >= current_date - 30
AND day < current_date
HAVING 100.0 * count(*) FILTER (WHERE loaded_at < day + interval '7 hours')
/ count(*) < 95;With 2 late days out of the 30 complete days, this returns days 30, on_time 28 and sli_pct of 93.3 and the objective is missed. If you track the load time in a single table already, the freshness query gives you that history. For arcodash, monitor sli_pct with < and 95 (drop the HAVING) and schedule the query daily; the alert docs cover the rest.
Pair it with a live check
The SLI is a lagging, 30-day view. It will not wake anyone when today’s load is late. Run a short-interval freshness check for the live case, and keep the SLI as the report on how often that check would have fired. Together they answer both “is it broken now” and “is this promise realistic”.
Setting the numbers
- Start from the consumer’s deadline, not from what the pipeline achieves today.
- Leave headroom. If the load finishes at 05:40 on a normal day, promising 07:00 gives you room for a bad night.
- Count misses honestly. Late loads that a person fixed by hand still count against the objective.
- Review the window. A 30-day window forgives a one-off quickly. A 7-day window is stricter and noisier.
See data observability for where SLIs fit among the other checks.
Questions
What is the difference between SLA, SLO and SLI?
The SLI is what you measure, for example minutes after midnight when the load finished. The SLO is the target for it, for example before 7am on 95 percent of days. The SLA is the agreement with the consumer that references the SLO, often with a consequence if it is missed.
Why is freshness the usual data SLI?
Consumers feel lateness first and can state it simply: I need this by 7am. It is also cheap to measure from a load timestamp. Volume and validity are common second SLIs.
Do I need a formal SLA?
Usually not at first. An internal SLO, measured and alerted on, gets most of the benefit. Write a formal SLA when another team or a customer depends on the data and needs to plan around it.