Choosing reliability targets and using error budgets.

August 27, 2026 Updated September 5, 2026 6 minute read By briskData Engineering

Reliability targets work when they reflect how customers experience the product. For a checkout page, the target needs to account for failed requests and how long customers wait. This guide shows the minimum set of decisions and numbers you need to run SLOs in practice.

How SLIs, SLOs, and SLAs differ

SLIs measure service behavior: 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 and may specify separate measurement rules. You need one or two SLIs per critical surface, each with a clear SLO that is easy to explain to a product manager.

Choose a target the service can sustain

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 the operating limits: batch jobs, dependencies, and deploy schedules all limit what is possible. Pick a target the team can sustain with its staffing and infrastructure. Example targets include 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.

Calculation example

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

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 using the budget compared to how fast the window is elapsing. Burn rate lets the team compare a brief spike in errors with a smaller, sustained error rate.

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 based on how long users can tolerate a failure. Page on short-window spikes; track smaller, sustained errors with tickets and dashboards.

Dashboards and alerting that track to the budget

Show the error budget on the dashboard: current burn rate, budget remaining, and the windows that drive alerts. Choose measurement windows based on how long users can tolerate a failure. The examples here use five minutes, one hour, six hours, and one day. Page when short-window burn is severe; use tickets for smaller, sustained errors. 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

Pause deployments when the remaining budget is too small to support further changes safely. Use a simple rule that operators can quote without looking it up. When the burn rate falls below the agreed threshold, resume deployments and record which mitigations remain in place: 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.

Using the budget in release decisions

Product and operations teams can use the remaining budget to discuss release risk. They might accept a temporary latency increase for a scheduled campaign, or postpone a release while engineers address recurring failures.

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

Review SLOs during daily operations as well as periodic reporting. 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. Include the deployment freeze rule and its current status in the on-call channel topic.

Review the numbers at standup during an incident week, during retrospectives to prioritize fixes, and when planning releases before a traffic peak. Use those reviews to schedule reliability work alongside product changes.

Integrate SLOs with incident response

Connect burn-rate alerts to incident procedures. Include the first checks in the alert: 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. Review whether those steps reduce the time needed to restore service.

After recovery, record what would have prevented the burn or reduced its impact. Reliability debt items should be bounded 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, separate immediate mitigations from the redesign work.

Common mistakes to avoid

Copying a target from the internet. A 99.99% goal may require more staffing and infrastructure than the team has. 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.

Changing the measurement window. 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. Too many pages make it harder to identify urgent incidents. Page when service failures require an immediate response. Track smaller, sustained failures with tickets and dashboards.

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, avoid duplicate pages for the same customer impact. Measure whether users can complete their tasks across the regions.

Do we need SLAs? Not to operate well. SLAs are a product and legal decision. Use SLOs for operating decisions and agree SLA terms separately with the appropriate product and legal staff.