Setting Realistic SLOs, SLAs, and Error Budgets (Without Lying to Yourself)

The Difference Between SLO, SLA, and Error Budget

These three terms get conflated constantly. Before you set any targets, lock down the definitions your team will use.

SLI (Service Level Indicator) — the raw measurement. Availability percentage, p99 latency, error rate. A number you can observe.

SLO (Service Level Objective) — your internal target for that indicator. "We will maintain ≥ 99.5% availability measured over a rolling 30-day window." This is a commitment to yourself and your team.

SLA (Service Level Agreement) — a contractual, externally-facing promise, usually with financial penalties (service credits) if breached. SLAs should always be looser than your SLOs — typically by at least one half-step — because your SLO is your early warning system.

Error budget — the amount of unreliability your SLO permits. If your SLO is 99.5% availability over 30 days (43,200 minutes), your error budget is 0.5% of that: 216 minutes of allowable downtime.

Picking the Right Availability Target

The hardest part isn't the math — it's resisting the urge to write down "99.99%" because it sounds impressive.

What each nine actually costs you

Before committing to a number, answer these questions honestly:

• What does your dependency chain look like? If your cloud provider publishes 99.95% for a managed database, your service cannot credibly promise more than that without additional redundancy.
• What does your deployment frequency look like? Every rolling restart or database migration eats into your budget.
• Do you have on-call coverage with a realistic response time? A 15-minute median time-to-acknowledge alone can consume a 99.99% budget in a single incident.
• What are users actually experiencing? Check your monitoring data for the last 90 days before setting a target, not after.

Defining the Measurement Window and Method

An SLO without a clear measurement window is meaningless. Common choices:

• Rolling 28 or 30 days — smooths out one-off incidents and aligns with billing cycles. Preferred for most production services.
• Calendar month — easier to report against but can make a bad month look better or worse depending on when incidents fall.
• Trailing quarter — useful for platform teams with slower-moving contracts.

Be explicit about what counts as downtime. A health check returning HTTP 200 but serving error pages to users is downtime. Define your SLI at the level users experience it, not at the level your load balancer sees.

This is where external monitoring matters. Internal metrics can miss the gap between "our servers think they're fine" and "users in Frankfurt cannot reach the login page." Running synthetic checks from multiple geographic regions — at one-minute or shorter intervals — gives you an SLI that reflects real-world availability, not just internal telemetry.

Using the Error Budget to Make Decisions

The error budget's real value isn't the number — it's the policy you attach to it.

A simple error budget policy

1. > 50% budget remaining: Normal operations. Ship features, run experiments, accept calculated risk.
2. 25–50% remaining: Yellow zone. Slow down risky deployments. Review recent incidents.
3. < 25% remaining: Freeze non-critical releases. Focus engineering time on reliability work.
4. Budget exhausted: Incident review required before any new feature work resumes. Notify affected SLA customers if applicable.

Document this policy in your runbook before an incident, not during one. Teams that define the policy in the moment consistently make worse decisions.

Writing SLAs That Won't Hurt You

If you're putting SLAs in contracts, a few practical rules:

• Set the SLA target 10–20% below your SLO. If your internal SLO is 99.9%, your SLA might promise 99.5%.
• Define the credit schedule clearly (e.g., 10% service credit for availability between 99.0–99.5%, 25% below 99.0%).
• Exclude scheduled maintenance windows, upstream provider outages, and customer-caused incidents — but define these exclusions precisely to avoid disputes.
• Specify how customers report and claim credits. Make it easy, or you'll erode trust faster than the downtime did.

Key Takeaways

• Your SLO should be your honest internal target; your SLA should be easier to hit than your SLO.
• Pick availability targets based on your actual infrastructure and deployment data, not aspiration.
• Define downtime from the user's perspective, measured externally where possible.
• Attach a written policy to your error budget so it drives real decisions, not just dashboards.
• Revisit SLOs quarterly — as systems mature, targets should tighten, not stay frozen.