What is an SLO? Error budgets for small teams

Your app does not need to be up 100% of the time. Chasing that number is how small teams burn out, freeze deploys, and still get paged at 2 a.m. The healthier question is: how reliable does this actually need to be, and how do we know when we have spent our margin? That is exactly what an SLO answers. So, what is an SLO? It is a target for how well a service should behave, written as a number you agree on in advance — and it comes with a built-in budget for the times you fall short. You do not need a platform team or a reliability org to use one. You need one good metric and a number to hold it against.

SLI, SLO, SLA: the three letters that matter

These get muddled constantly, so here is the short version:

• SLI (indicator): the thing you measure. "The percentage of requests that returned without an error" or "requests served in under 300ms."
• SLO (objective): the target for that indicator. "99.5% of requests succeed over 30 days."
• SLA (agreement): a contractual promise to a customer, usually with penalties. Most small teams have SLOs long before they have SLAs.

Start with the SLI and SLO. The SLA can wait until a customer asks for one.

What is an SLO worth to a small team?

An SLO turns vague anxiety into a decision rule. Instead of arguing about whether the app is "reliable enough," you look at a number. It also protects your time: anything healthier than the target is, by definition, good enough to leave alone and go build features. The point of an SLO is not perfection — it is permission to stop polishing once you are inside target.

Error budgets: the part people skip

If your SLO is 99.5% success over 30 days, then 0.5% of requests are allowed to fail. That 0.5% is your error budget — a concrete allowance you spend down as things break.

This reframes incidents. A handful of errors is not a crisis; it is budget spend. But when you have burned most of the month's budget by the 10th, that is your signal to stop shipping risky changes and shore things up instead. The budget makes the trade-off between speed and stability explicit, so you are not guessing.

How to start with one SLO this week

You do not need a dashboard wall. Pick one:

1. Choose one user-facing SLI. Request success rate is the easiest place to start.
2. Set a target you can defend. 99% or 99.5% over 30 days is plenty for most apps. Round numbers are fine.
3. Watch the burn, not every blip. Care about how fast you are spending the budget, not about individual errors.
4. Decide the rule in advance. "If we burn 75% of the budget before month-end, we pause feature work." Agreeing now beats negotiating mid-incident.

Lookout tracks SLOs and error budgets for you from the same error and request data it already ingests, so you can see remaining budget and burn rate without wiring up a separate metrics stack. Set the target once and let it watch the margin.

When NOT to bother

Skip SLOs on internal tools nobody pages about, prototypes, and anything pre-launch. SLOs earn their keep when real users feel the downtime and you have to make trade-offs about where your limited time goes. Before that, you are adding ceremony to a problem you do not have yet.

The takeaway

An SLO is just a reliability target you agree on, paired with an error budget that tells you when you have spent your margin. For a small team, that is the difference between reacting to every error and calmly deciding which ones are worth your weekend. Start with one SLI, one number, and one rule. Spin up a free Lookout project — 10,000 events a month, no credit card — and put your first error budget on the board today.