SLI/SLO Definition Template for Engineering Teams

An SLO is an internal target that your team commits to. An SLA is a contractual commitment to customers, usually with financial penalties for violations. SLOs should be tighter than SLAs. If your SLA guarantees 99.9% uptime, set your internal SLO at 99.95% so you have a buffer before violating the contract.

Start with availability (the most fundamental: did the request work?). Add latency if user experience is sensitive to speed (search, checkout, dashboards). Add correctness if data accuracy matters (financial calculations, analytics, reports). Most services need availability + latency. Data services add freshness. Financial services add correctness.

Each incident consumes a portion of the budget. Track them cumulatively. If three small incidents each burn 15% of the budget, you are at 45% consumed. The policy thresholds (50%, 25%, 0%) apply to the cumulative total. After a month with heavy budget consumption, the next month starts fresh (rolling window resets).

Frame the error budget as protecting the user experience. When the budget is healthy, product gets full feature velocity. The policy only restricts feature work when users are experiencing unacceptable reliability. Show the math: "We have 43 minutes of downtime budget. We have used 30 of them. One more 15-minute incident means our users experience more outages than our target allows." Most PMs agree that shipping features into an unreliable service does not help users.

Yes, but with simpler SLIs and looser targets. Internal services (background jobs, data pipelines) affect user experience indirectly. A failed export job means a user does not get their report. A stale analytics pipeline means dashboards show old data. Set SLOs that reflect the impact on the end user, not the internal consumer. A 99.0% completion rate for background jobs is often appropriate.