--- title: "What are SLAs, SLOs and SLIs?" canonical: https://enum.co/learn/what-is-an-sla-slo-sli locale: en topic: Operations publishedAt: 2026-11-05 updatedAt: 2026-11-05 author: "Max Heyer" summary: "SLAs, SLOs and SLIs describe service reliability: an SLI measures it, an SLO sets a target for that measure, and an SLA puts a target into a contract." --- # What are SLAs, SLOs and SLIs? SLAs, SLOs and SLIs describe service reliability: an SLI measures it, an SLO sets a target for that measure, and an SLA puts a target into a contract. After reading this you will be able to: - Tell an SLI, an SLO and an SLA apart - Turn an availability target into an error budget - Read an SLA for what it covers and leaves out ## What are SLAs, SLOs and SLIs? SLAs, SLOs and SLIs are three layers of describing how reliable a service is. A service level indicator (SLI) is a number you measure, such as the share of requests that succeed, and a service level objective (SLO) is the target for it. A service level agreement (SLA) is a contract that states targets and what happens when they are missed. Think of a pizza place. The SLI is how many minutes each delivery took, and the SLO is the kitchen's own goal of 30 minutes. The SLA is the printed promise that a late pizza is free. ## What makes a good SLI? A good SLI tracks what users feel, not what a server feels. CPU load says little; failed checkouts say a lot. The cleanest form is a ratio: good events divided by valid events, which always lands between 0% and 100%. Common SLIs are: - Availability: the share of well-formed requests that succeed. - Latency: the share of requests answered faster than a threshold, such as 300 ms. - Freshness: the share of data updated more recently than a time threshold. - Durability: the share of stored data that can still be read. ## How do SLOs and SLAs relate? An SLO is an internal goal. Missing it means the team changes its priorities, not that anyone pays. An SLA adds consequences, most often service credits or other financial penalties. ### Keep a margin Teams set their internal SLO tighter than the SLA they sign. If the SLA promises 99.9%, the team might aim for 99.95%. The gap gives room to fix a slow decline before a customer is owed anything. ### Pick the window Targets are measured over a window. A rolling 30-day window matches what users remember, since an outage does not vanish on the first of the month. A calendar month matches billing and planning, which is why contracts often use it. ### What an SLA leaves out An availability SLA says how often a service answers, not how fast someone helps when it does not. Response time for incidents is a separate promise. Check which components an SLA covers, how downtime is measured, and what the credit is worth against your actual loss. ## What is an error budget? The error budget is 100% minus the SLO: the amount of failure the target still allows. At 99.9% over a 30-day month, that is 0.1%, or about 43 minutes of full downtime. Counted in requests, 1,000,000 requests a month allow 1,000 failures. ### Spending the budget The budget turns reliability into a decision rule. While budget is left, the team ships features and takes risks such as upgrades. When it runs out, an error budget policy kicks in, typically a freeze on risky changes until the service is back within its SLO. ## How enum handles SLAs enum gives a 99.9% availability SLA for the Kubernetes control plane API, object storage, load balancers and NAT. [Enterprise Support](/enterprise-support) adds a named contact and 24/7 handling of critical incidents, with response times down to 15 minutes. The exact times are written into your contract. ## FAQ **Is 99.9% the same as 99.99%?** No. Over a 30-day month, 99.9% allows about 43 minutes of downtime, while 99.99% allows about 4 minutes. Each extra nine cuts the error budget by a factor of ten. **Can a provider SLA cover my application?** Only the parts the provider runs. A provider SLA covers the provider's components, such as a control plane or storage API. Your application's availability depends on your own design, so define SLOs for your own services too. **Should every metric get an SLO?** No. Pick a handful of SLIs that match what users notice, such as successful requests and response latency. Too many targets dilute attention, and nobody knows which breach actually matters.