SLOs came from teams with thousands of services and a reliability department. The idea is simpler than its reputation, and a three-person team can use it to settle its most common argument: ship, or stabilise?
A service level objective is a target you set for your own service — say, 99.9% of checks succeed over a rolling 30 days — and the error budget is the failure that target allows: at 99.9%, about 43 minutes of downtime a month. An SLA is the version of that promise you make to a customer, with consequences; the SLO is the stricter internal target you run against so the SLA is never at risk. The budget turns reliability from a feeling into a number with a decision attached: while budget remains, ship; when it is spent, stabilise. For a small team, the whole practice can be one declared target per asset and a health score that shows budget remaining.
| SLA | External promise to a customer, in a contract, with credits or penalties. Example: 99.5% monthly availability. Reporting against it. |
|---|---|
| SLO | Internal target you actually run to, stricter than the SLA so the SLA is safe. Example: 99.8%. |
| SLI | The measurement — the fraction of checks that succeeded, the fraction of requests under 500 ms. What the SLO is a target for. |
| Error budget | What the SLO allows to fail: 100% − SLO, expressed as minutes or failed requests over the window. |
Over a 30-day window (43,200 minutes):
| 99% | 432 minutes of failure allowed — 7 h 12 min |
|---|---|
| 99.5% | 216 minutes — 3 h 36 min |
| 99.9% | 43 minutes |
| 99.95% | 21.6 minutes |
| 99.99% | 4.3 minutes — not a target for a small team on ordinary hosting |
Budget burns as failures are confirmed. A 25-minute incident on a 99.9% asset spends 58% of the month's budget. Two such incidents and the budget is gone with two weeks left — which is precisely the information the team needs. Latency SLOs work the same way with requests instead of minutes: "99% of checks under 800 ms" gives a budget of 1% slow checks. How the layers roll up.
This is the part that earns its keep. Write a one-paragraph error budget policy:
While an asset has error budget remaining in the current window, feature work proceeds normally. When the budget is exhausted, feature deploys to that asset stop until the window recovers or the cause is fixed; engineering time goes to reliability. Budget spent on a dependency outage counts unless the SLA excludes it.
The value is not the rule itself but that it was agreed in advance. "Should we ship this or fix the flakiness first?" is no longer a negotiation between the founder and the engineer; it is a look at a number. Deploy correlation tells you which deploys spent budget; catching small bugs early is how you stop spending it.
Many dashboards show a health score — 87/100 — that blends uptime, latency, errors and "trend" with weights nobody remembers. The question "what does 87 mean?" has no answer. Budget remaining does: "this asset has used 31% of its monthly error budget" is a statement about the promise you made and how much room is left. It rises as the window rolls forward and drops when checks fail; it is comparable across assets on different tiers; and it tells a client exactly where the month stands. Monitoring says something is wrong; the budget says how much it cost.
| SLO | Internal target you run to; stricter than the SLA |
|---|---|
| SLA | External promise with consequences |
| Error budget | 100% − SLO, as minutes or failed requests over the window |
| 99.9% / 30 days | 43 minutes of failure allowed |
| Decision rule | Budget remaining → ship; budget spent → stabilise |
| Health score | Budget remaining, per asset, against its declared tier |
| How many | One SLO per user-visible asset |
An error budget is the amount of failure a service level objective permits over a window. If the SLO is 99.9% availability over 30 days, the error budget is 0.1% of that window — about 43 minutes of downtime. Confirmed failures spend the budget; while budget remains the team ships normally, and when it is exhausted feature work pauses in favour of reliability.
An SLA is the external promise made to a customer, usually in a contract with credits or penalties. An SLO is the internal target the team actually runs to, set stricter than the SLA so the SLA is never at risk. The SLI is the underlying measurement — for example the fraction of checks that succeeded — that both are targets for.
Subtract the SLO from 100% and multiply by the window. For 99.9% over a 30-day month of 43,200 minutes: 0.1% × 43,200 = 43.2 minutes. For 99.5%: 216 minutes, or 3 hours 36 minutes. For 99%: 432 minutes, or 7 hours 12 minutes. Latency SLOs use requests or checks instead of minutes.
A small team benefits more than a large one, because it has no reliability department to arbitrate the ship-or-stabilise argument. One declared target per user-visible asset, an error budget derived from it, and a one-paragraph policy about what happens when the budget is spent replaces that argument with a number.
Error budget remaining against a declared target is the most honest basis: it is a statement about a promise and how much room is left, comparable across assets on different tiers, and explainable to a client. Blended scores that weight uptime, latency and errors by hidden coefficients answer the question "what does 87 mean?" with silence.
One the architecture can actually deliver. A single-region deployment on ordinary hosting with no on-call rotation can honestly target 99.5%; 99.9% needs redundancy and a response process; 99.99% is not a small-team target. Set the SLO slightly tighter than whatever SLA you offer customers, and tighten it as the system earns it.
Merik's health score is exactly this: each asset carries a declared SLA tier, and its health is the error budget remaining against that tier over the window — measured from the outside by the same checks a user's request would take, not from the server's opinion of itself. Confirmed failures spend budget; recovered warnings do not. The score is comparable across a client's assets on different tiers and is the number the monthly SLA report is built on.
Deploys from GitHub and Vercel webhooks and provider incidents from vendor status feeds sit on the same timeline, so you can see which deploy or which dependency spent the budget — and apply an error budget policy with evidence rather than argument. See the Digital Operations module.
Tiers and their minutes, the seven sections, and how to present a quiet month.
Every layer of application health, and how to roll them into one honest score.
Observe, baseline, warn, respond, learn — the full loop that prevents incidents instead of narrating them.