SLOs and Error Budgets for SaaS Teams: Turning Reliability into Release Decisions
How SaaS teams choose SLIs, set SLOs, calculate error budgets, alert on burn rate and use an error budget policy to decide when to ship and when to fix.
How do SLOs and error budgets work?
Pick a few service level indicators (SLIs) that reflect what users experience, such as successful requests or fast page loads for key journeys. Set a service level objective (SLO) for each over a rolling window, for example 99.9% of checkout requests succeed over 30 days. The gap between the SLO and 100% is the error budget. Alert when the budget is burning fast, and agree an error budget policy: while budget remains, ship features; when it is exhausted, prioritise reliability. SLOs turn reliability arguments into a shared, measurable decision.
This guide is for engineering and product leads at SaaS companies who want reliability targets that influence what gets built.
Key takeaways
- Measure user journeys, not servers.
- Start with two or three SLOs, not dozens.
- Set SLAs looser than SLOs.
- Alert on burn rate, not on every error spike.
- Write the error budget policy before you need it.
- Review SLOs quarterly against user feedback and incidents.
Definitions
| Term | Meaning | Example |
|---|---|---|
| SLI | A ratio of good events to valid events | Checkout API requests returning success within 1 second / all checkout requests |
| SLO | Target for an SLI over a window | 99.9% over a rolling 30 days |
| Error budget | 1 − SLO, over the window | 0.1% of requests, or about 43 minutes |
| Burn rate | How fast budget is being used relative to the window | Burn rate 2 exhausts a 30-day budget in 15 days |
| SLA | Contractual commitment with remedies | 99.5% monthly availability with service credits |
Choosing SLIs
Start from the journeys users care about: signing in, loading the main dashboard, saving work, checking out, receiving webhooks. For each, pick indicators measured as close to the user as practical, at the load balancer or API gateway rather than inside one service.
- Availability: share of valid requests that succeed (exclude client errors you cannot fix).
- Latency: share of requests faster than a threshold, rather than an average.
- Correctness: share of jobs or calculations producing the right result.
- Freshness: share of time data is updated within an agreed delay, for pipelines and syncs.
- Durability: for storage, share of data retrievable.
Error budget arithmetic
Time-based budgets are easy to explain; request-based budgets are fairer when traffic varies. Both come from the same calculation.
| SLO | Budget over 30 days (time) | Failed requests allowed per 1,000,000 |
|---|---|---|
| 99% | 7.2 hours | 10,000 |
| 99.5% | 3.6 hours | 5,000 |
| 99.9% | 43.2 minutes | 1,000 |
| 99.95% | 21.6 minutes | 500 |
| 99.99% | 4.3 minutes | 100 |
# Good events / valid events over 30 days
sum(rate(http_requests_total{route="/checkout", code!~"5.."}[30d]))
/
sum(rate(http_requests_total{route="/checkout"}[30d]))Alerting on burn rate
Alerting on every error spike wakes people for blips; alerting on SLO breaches alerts too late. The Google SRE workbook recommends multiwindow, multi-burn-rate alerts. A common starting point for a 30-day SLO:
| Budget consumed | Long window | Short window | Burn rate | Response |
|---|---|---|---|---|
| 2% | 1 hour | 5 minutes | 14.4 | Page |
| 5% | 6 hours | 30 minutes | 6 | Page |
| 10% | 3 days | 6 hours | 1 | Ticket |
Pro tip
The short window stops alerts firing long after a problem has been fixed. Tune thresholds for low-traffic services, where a handful of failures can look like a fast burn.
Writing an error budget policy
The policy is what turns numbers into decisions. Agree it between engineering and product leadership in advance, so it is not negotiated during an incident. Google publishes an example error budget policy.
- What happens when budget is exhausted: pause non-urgent releases, prioritise reliability fixes.
- Exceptions: security fixes, legal requirements and agreed critical launches.
- When a single incident uses a large share of budget, a post-incident review is mandatory.
- Who decides, and how disagreements are escalated.
- When the policy and SLOs are reviewed.
SLOs in multi-tenant SaaS
An aggregate SLO can look healthy while one large customer has a bad week. Track SLIs per tenant or tier for important accounts, and consider separate SLOs for enterprise tiers with their own SLAs. Dependencies matter too: if a payment provider or identity provider fails, your users still see failure, so decide whether to count it and how to degrade gracefully. See scaling SaaS applications and multi-tenant SaaS architecture.
Connecting SLOs to releases
Deployments cause a large share of incidents, so tie release practices to the budget: progressive rollouts and automatic rollback when burn rate spikes, feature flags to turn off risky changes, and release freezes only when the policy says so. See zero-downtime deployments and feature flag implementation.
Hypothetical example: a B2B scheduling platform
This example is hypothetical. A scheduling SaaS team argued every month about whether to slow down for reliability. It defined three SLOs (sign-in availability 99.9%, booking API success 99.9%, calendar sync freshness within 5 minutes for 99% of the time), added burn-rate alerts, and agreed that non-urgent releases pause when a 30-day budget is exhausted. In the first quarter, a sync bug used most of the freshness budget; the team spent two sprints on the sync pipeline, and the debate became a decision based on shared numbers.
Common mistakes
- SLOs for every service instead of user journeys.
- Targets copied from SLAs or set at 99.99% by default.
- Averages instead of thresholds for latency.
- No error budget policy, so the numbers change nothing.
- Alerting on SLO breach instead of burn rate.
- Never revisiting targets.
Sources
Conclusion
SLOs work when they measure what users feel, the error budget is calculated honestly, alerts follow burn rate, and a written policy says what happens when the budget is gone. Start with a few journeys, review quarterly, and use the budget to decide between features and reliability rather than arguing about it. For the monitoring underneath, see application monitoring and observability.
Want reliability targets your team will actually use?
ZSpace Labs is a remote-first technology studio that works with clients globally on SaaS engineering, monitoring and release pipelines. If it would help to define SLIs, SLOs and alerts for your product, we are happy to talk it through.
Common questions.
An SLI (service level indicator) is a measurement, such as the share of requests that succeed. An SLO (service level objective) is the target for that measurement over a period, such as 99.9% over 30 days. An SLA (service level agreement) is a contract with customers, usually with credits, and should be looser than the internal SLO.