Set reliability targets users can actually feel.

August 27, 2026 6 minute read By briskData Engineering

Reliability targets work when they reflect how customers experience the product. A number like 99.9% means nothing to a person waiting for a checkout page; what matters is whether an outage is short, rare, and contained. This guide shows the smallest set of decisions and numbers you need to run SLOs in practice.

SLOs vs. SLAs vs. SLIs: the minimum you need

SLIs are the measurements users feel: request success rate, p95 latency on the checkout API, or error‑free minutes of streaming. SLOs are the targets you aim to meet for those SLIs over a time window (for example, 99.9% monthly availability). SLAs are contracts with customers—keep them out of your day‑to‑day math. You need one or two SLIs per critical surface, each with a clear SLO that is easy to explain to a product manager.

Pick a target: customer tolerance and system reality

Start from how long a user will tolerate failure before they abandon a task or lose data. A consumer signup form may survive a brief blip; a B2B payment API usually cannot. Then check system reality: batch jobs, dependencies, and deploy schedules all limit what is possible. Pick the tightest target you can operate without constant heroics. The right answer is specific: 99.9% on the checkout API, 99% on a non‑critical admin page, and a latency SLO on the product detail view where speed drives conversion.

Math you actually use

Error budget and burn rate, defined

Error budget = 1 - target SLO. For a 99.9% monthly availability target, the budget is 0.1% of the month.

Budget minutes = error budget × minutes in window. In a 30-day month: 0.001 × 43,200 ≈ 43.2 minutes.

Burn rate = consumed budget ÷ elapsed time (as a fraction of window). A burn rate of 2x means you will exhaust the budget in half the remaining time if nothing changes.

Example	Value
Target SLO	99.9% monthly
Error budget	0.1% of month
Minutes this month	43,200
Budget minutes	43.2 minutes
Incident so far	12 minutes of user-visible errors
Elapsed month	10 days (33.3%)
Burn rate	(12 ÷ 43.2) ÷ 0.333 ≈ 0.83x

How to calculate error budget and burn rate

Once you set a target, the rest is arithmetic. The error budget is the slice of time you are allowed to be out of SLO. Track budget consumption in your monitoring tool, then compute burn rate: how quickly you are eating the budget compared to how fast the window is elapsing. Burn rate normalizes a short sharp incident and a slow leak on the same scale, which makes alerting rules simple and consistent.

Alerting that matches impact

Burn‑rate thresholds and what to do

Window	Burn rate	Alert	Action
5 minutes	≥ 14x	P1 page	Incident response; rollback or mitigate immediately
1 hour	≥ 6x	P2 page	Reduce blast radius; disable risky paths
6 hours	≥ 3x	P3 ticket	Assign owner; plan a near‑term fix
1 day	≥ 2x	P3 ticket	Prioritize reliability work in the next sprint

Pick windows that reflect how long users feel pain. Page on short‑window spikes; track slower leaks with tickets and dashboards.

Dashboards and alerting that track to the budget

Dashboards should put budget front and center: current burn rate, budget remaining, and the windows that drive alerts. Prefer a small number of windows that match user pain: five minutes, one hour, six hours, and one day cover most products. Page only when short‑window burn is severe; ticket slower leaks. Add a “freeze if” tile that shows whether your governance rule is active right now.

Governance

When to freeze deploys—and when to spend budget

Freeze when the monthly burn rate ≥ 1x and the daily burn rate ≥ 2x.
Spend budget on planned risk: migrations, major releases, or peak traffic protections.
Unfreeze when the daily burn falls below 1x for 48 hours and mitigations are verified.
Always allowed: fixes that reduce risk (config changes, feature flags off, bug fixes).

Governance: when to freeze deploys and when to spend the budget

Freezing deploys is not punishment—it is a tool to protect users when risk is already high. Use a simple rule that operators can quote without looking it up. When burn cools, unfreeze and record what mitigations stick: rate limits, feature flags, circuit breakers, backpressure. Spend budget on planned risk only when the value is clear and rollback is ready: migrations with dual‑writes, major releases behind flags, and extra capacity for a known traffic peak.

Where this math pays off

Targets and budgets turn reliability into an engineering lever you can manage. Product can accept a temporary hit to latency if it delivers a feature in time for a campaign. Operations can justify a freeze because the numbers say the risk is real. Finance can see when reliability work replaces waste with margin. That alignment is the point.

If you want a quick starting point, our free SLO & error budget calculator does the math and shows the burn‑rate thresholds described above.

Choose SLIs that represent user experience

Pick signals that correlate with what a human is trying to do. For a retail site, the add‑to‑cart and checkout APIs usually matter more than the homepage. For a streaming service, startup latency and rebuffering time beat raw 200/500 counts. A good SLI is specific, measurable in production, and hard to game. If an engineering team can “improve” the metric in a way users would not notice, pick a better one.

Most teams start with two classes of SLIs: availability (success ratio over a rolling window) and latency (p95 or p99 response time). Track them per critical surface rather than globally. A single site‑wide number hides the fact that users can buy gifts but cannot manage subscriptions, or that the admin panel is fast while the API consumers use is slow.

Make SLO math visible where engineers work

SLOs fail when they live in a quarterly slide deck. Put the numbers in the tools the team opens every day. Add burn‑rate widgets to your Grafana or Datadog dashboards. Include “budget remaining” next to latency graphs on service runbooks. In on‑call rotations, include the freeze rule and current state in the channel topic so the question “are we frozen?” has a one‑line answer.

Engineering managers should hear the numbers in regular rituals: at standup during an incident week, in retro to decide which hazards get fixed, and in planning when product asks whether a risky change can ship before a predictable traffic peak. The point is not ceremony; it is making reliability an explicit part of how the team chooses work.

Integrate SLOs with incident response

Burn‑rate alerts are only the beginning. Tie them into incident response so an alert comes with the first three things to check: recent deploys, feature flag changes, and known fragile dependencies. Add runbooks that teach responders how to reduce burn fast: shed load with backpressure, fall back to cached reads, or lower expensive timeouts on a dependency that is failing. The goal is not a perfect postmortem; it is a steady drop in time‑to‑mitigation.

After recovery, record what would have prevented the burn or reduced its impact. Reliability debt items should be small and easy to schedule: implement token buckets on a hot route, pre‑warm caches on deploy, move a chatty component behind a queue, or add circuit breakers to protect a downstream system that tends to fail cold. If a fix takes weeks, split it: today’s guardrails first, deeper redesign later.

Common mistakes to avoid

Copying a target from the internet. A 99.99% goal looks good on a slide and dooms a small team to burnout. Start with a target you can hold for a quarter and tighten later if users need it.

Picking SLIs you cannot measure. If routing or edge caching hides failures, run synthetic checks from multiple regions. If you rely on client‑side telemetry, implement server‑side probes until coverage is solid.

Shrinking the window to “win.” Teams sometimes switch to weekly windows to ease the math. Short windows are useful for alerting; long windows make better contracts with product because they average over normal noise. Use both, but keep the target meaningful.

Paging on everything. Alert fatigue destroys good math. Page only when users are in pain. Tickets and dashboards are the right shape for slow leaks and chronic small misses.

FAQ

Should SLOs cover internal services? Yes, if a team’s daily work depends on them and breakage causes user‑visible harm. An internal queue that loses jobs deserves a target as much as a checkout API does.

What about regional outages? If your product is multi‑region, set SLOs per region and globally. During a single‑region cloud event, do not page twice for the same pain. Users feel “can I do my task right now,” not whether a zone is healthy.

Do we need SLAs? Not to operate well. SLAs are a product and legal decision. Run your SLOs to protect users; write SLAs to protect promises.