SLO Document Template
What it is
A Service Level Objective (SLO) document is a formal specification of the reliability targets for a service, along with the metrics used to measure them, the error budget derived from those targets, and the policies that govern how the error budget is used. It is the contractual baseline for a service's reliability: below the SLO target means the service is failing its users; above it means the team may have reliability headroom to take on more risk.
An SLO document defines three interconnected concepts. Service Level Indicators (SLIs) are the specific, measurable signals used to assess service health — typically availability, latency, error rate, throughput, or data freshness. Service Level Objectives are the targets for those indicators over a rolling time window. The error budget is the allowable amount of non-compliance with the SLO — the difference between 100% and the target, expressed as time or request count — which the team can "spend" on risky changes, planned maintenance, and experimentation.
SLO documents are distinct from Service Level Agreements (SLAs). An SLA is a contract with customers that specifies penalties for non-compliance; an SLO is an internal engineering target that is typically more stringent than the SLA. The SLO is set conservatively enough that SLA violations should be rare even when SLOs are occasionally missed.
Why it exists
Without explicit reliability targets, engineering teams face an implicit expectation of 100% uptime — which is both technically impossible and produces perverse incentives. Teams that chase 100% uptime slow down feature delivery to an unsustainable degree, avoid necessary risky changes, and still experience incidents because the system has not been designed with explicit failure modes in mind. SLOs replace this impossible standard with an explicit, negotiated target that reflects the actual reliability needs of users.
The error budget concept fundamentally changes the relationship between reliability and velocity. When the budget is full, teams can ship features aggressively — reliability is good enough. When the budget is depleted, teams must focus on reliability work before shipping new features. This creates a data-driven, automatic feedback loop between reliability and feature velocity, replacing the subjective, political negotiation that otherwise governs how engineering time is allocated.
SLO documents also create shared understanding between engineering and business stakeholders. They make explicit what reliability costs: achieving 99.99% availability for a service requires significantly more engineering investment than 99.9%. When product managers understand that their feature velocity is directly linked to the error budget consumed by incidents, reliability work moves from an abstract "nice to have" to a concrete business constraint.
When to use
- For every production service that has user-facing impact, particularly those where degradation affects revenue, user experience, or compliance obligations.
- When establishing or formalizing an on-call rotation — on-call engineers need explicit definitions of "healthy" and "unhealthy" to make paging decisions.
- When negotiating external SLAs with customers — the internal SLO should be the foundation for any customer-facing service level commitments.
- When teams are struggling to balance reliability work against feature delivery and need a data-driven framework for the conversation.
- During service maturity reviews or platform engineering assessments where a catalog of service SLOs is needed to understand the reliability posture of the organization.
When NOT to use
- For internal tools or services with no user-facing impact where informal reliability expectations are sufficient and the overhead of SLO tracking is not warranted.
- When measurement infrastructure does not yet exist to compute the SLIs — an SLO you cannot measure is not an SLO, it is a wish. Build the metrics first.
- When the SLO is set so high (99.999%+) that the error budget is effectively zero, eliminating the error budget's function as a change velocity enabler.
- As a way to hold engineering teams accountable without giving them the authority and resources to meet the target — SLOs without investment in the reliability work needed to achieve them produce frustration rather than improvement.
Template
# SLO Document: [Service Name]
**Service:** [Service name]
**SLO Owner:** [Name — the engineer or team accountable for maintaining this document and the SLOs]
**Stakeholders:** [Product Manager], [Engineering Lead], [Customer Success]
**Status:** Draft | Active | Under Review | Deprecated
**Effective Date:** [YYYY-MM-DD]
**Next Review Date:** [YYYY-MM-DD]
**Related SLA:** [Link to customer-facing SLA if one exists]
---
## Service Overview
**Description:** [What this service does in 2–3 sentences]
**Critical User Journeys:**
1. [Journey 1 — e.g., "User submits an order and receives a confirmation within 3 seconds"]
2. [Journey 2 — e.g., "User views their order history and sees up-to-date status"]
3. [Journey 3]
**Dependencies:**
- Upstream: [Services that call this service]
- Downstream: [Services this service calls — failures here affect our SLIs]
- External: [Third-party dependencies — payment processors, email providers, CDNs]
---
## Service Level Indicators (SLIs)
### SLI 1: Availability
**Definition:** The proportion of HTTP requests to the service that return a non-5xx response code.
**Measurement:**
```
SLI = (requests with status 2xx or 3xx or 4xx) / (total requests)
measured over a rolling 28-day window
excluding requests filtered by exclusions listed below
```
**Data source:** [Prometheus metric name / CloudWatch metric / Datadog query]
**Dashboard:** [Link to the availability dashboard]
---
### SLI 2: Latency
**Definition:** The proportion of requests to the [primary endpoint or user journey] that complete within the latency threshold.
**Measurement:**
```
SLI = (requests completing in <= 300ms) / (total successful requests)
measured over a rolling 28-day window
for the endpoint: POST /v1/orders
```
**Threshold:** 300ms (p99)
**Data source:** [Prometheus histogram metric or equivalent]
**Dashboard:** [Link to the latency dashboard]
---
### SLI 3: Error Rate (optional — often covered by Availability)
**Definition:** The proportion of requests that complete without an application-level error (distinct from HTTP 5xx).
**Measurement:**
```
SLI = (requests that complete without error) / (total requests)
```
**Data source:** [Application metric name]
---
### SLI 4: Data Freshness (for data pipelines / async services)
**Definition:** The proportion of time during which the service's data was last updated within the freshness threshold.
**Measurement:**
```
SLI = (minutes where data age <= 5 minutes) / (total minutes in window)
```
**Threshold:** Data must not be older than 5 minutes
**Data source:** [Metric: pipeline_last_successful_run_age_seconds]
---
## Service Level Objectives (SLOs)
| SLI | Target | Window | Dashboard |
|-----|--------|--------|-----------|
| Availability | 99.9% | Rolling 28 days | [Link] |
| Latency (p99 <= 300ms) | 95% | Rolling 28 days | [Link] |
| Data Freshness | 99.5% | Rolling 28 days | [Link] |
**SLO notes:**
- These are internal engineering targets; the external SLA is set at [X]% (more conservative)
- SLOs apply to traffic excluding the exclusions listed below
- SLOs were last calibrated against 6 months of historical data on [YYYY-MM-DD]
---
## Error Budget
### Error Budget Calculation
| SLI | SLO Target | Error Budget (28 days) |
|-----|------------|----------------------|
| Availability | 99.9% | 0.1% = **40.3 minutes** |
| Latency | 95.0% | 5.0% = **[X requests/day]** |
| Data Freshness | 99.5% | 0.5% = **201.6 minutes** |
### Error Budget Policy
**When error budget remaining > 50%:**
- Normal development velocity; risky changes are permitted
- On-call load is acceptable; no special action required
**When error budget remaining is 25%–50%:**
- Review upcoming risky deployments; additional testing or staged rollout required
- Notify stakeholders that reliability is tightening
**When error budget remaining is 0%–25% (budget alert):**
- No new risky feature deployments without explicit SLO Owner approval
- All remaining engineering capacity redirected to reliability improvements
- Weekly error budget review meeting with engineering lead and product manager
**When error budget is exhausted (budget freeze):**
- Feature deployments halted until budget is replenished OR SLO is formally revised
- Incident review triggered to understand root cause of exhaustion
- Escalation to engineering leadership
**Budget reset:** Error budget resets on a rolling 28-day basis (not calendar month).
---
## Alerting Policy
### Alert: Fast Burn (P1 — 1-hour window)
**Condition:** Error budget is being consumed at 14x the sustainable rate (would exhaust in 2 days)
**Alert:** `slo:availability:burn_rate_1h > 14`
**Severity:** P1 — Page on-call immediately
**Runbook:** [Link to runbook section]
### Alert: Slow Burn (P2 — 6-hour window)
**Condition:** Error budget is being consumed at 6x the sustainable rate (would exhaust in 5 days)
**Alert:** `slo:availability:burn_rate_6h > 6`
**Severity:** P2 — Page on-call during business hours
**Runbook:** [Link to runbook section]
### Alert: Budget Warning (P3 — daily check)
**Condition:** Less than 25% of error budget remaining for the rolling 28-day window
**Alert:** `slo:availability:budget_remaining_28d < 0.25`
**Severity:** P3 — Notify team channel, no page
**Response:** Schedule reliability review
---
## Review Cadence
| Review type | Frequency | Participants | Purpose |
|-------------|-----------|--------------|---------|
| Error budget review | Weekly (when budget < 50%) | Engineering lead, SLO owner, PM | Review consumption, prioritize reliability work |
| SLO calibration review | Quarterly | SLO owner, engineering lead | Validate targets against user needs and system capabilities |
| Annual SLO review | Annually | Engineering, Product, Customer Success | Review targets in light of product evolution and customer feedback |
---
## Exclusions
The following events are excluded from SLO calculation:
- Planned maintenance windows (requires 7-day advance notice in status page)
- Outages caused entirely by [named external dependency] with documented evidence
- Force majeure events as defined in the customer SLA
**Exclusion approval:** All exclusions require sign-off from the SLO Owner and Engineering Lead.
**Exclusion log:** [Link to exclusion tracking doc or spreadsheet]
Pros and cons
Benefits
- Creates a data-driven framework for balancing reliability investment against feature velocity, replacing subjective negotiations with objective error budget math.
- Aligns engineering, product, and business stakeholders around an explicit definition of "good enough" reliability for each service.
- Provides the foundation for meaningful on-call alerting — alerts tied to SLO burn rates are far less noisy than threshold-based alerts.
- Generates a historical record of service reliability that supports capacity planning, vendor negotiations, and customer trust conversations.
Pitfalls
- SLOs set without measurement infrastructure are aspirational targets that cannot be acted upon; you must be able to compute the SLI before setting the SLO.
- Overly tight SLOs (99.999%+) produce zero error budget and block all risky changes, eliminating the error budget's function as a change enabler.
- Gaming the exclusions list to avoid appearing to miss SLOs undermines the entire framework and erodes stakeholder trust.
- Error budget policies that exist on paper but are never enforced train engineers to ignore the budget, collapsing the feedback loop between reliability and velocity.
Writing guidance
Start with the user experience, not the metrics. The right SLIs are those that most directly measure whether users can accomplish the critical journeys you defined in the Service Overview. Availability of the API is only a good SLI if API availability is what users care about — for an async pipeline, data freshness may be more relevant. Do not let the availability of metrics drive your SLI selection; let user experience drive it and then find or build the metrics you need.
Calibrate SLO targets against historical performance, not aspirations. Pull 90 days of historical SLI data before setting targets. If your service has historically achieved 99.7% availability, setting an SLO of 99.9% is aspirational and will exhaust the error budget constantly, creating noise and eroding confidence in the framework. Start with a target slightly more ambitious than current performance and tighten it as the team improves the service. A target you can actually measure, monitor, and make decisions against is more valuable than a number that looks impressive on paper.
The error budget policy is the most important section and the most frequently omitted. Without a policy defining what happens as the budget is consumed, the error budget is just a number on a dashboard. Write the policy before you need it, get explicit sign-off from engineering and product leadership, and rehearse it with a tabletop exercise before the first real budget exhaustion event. The policy only works if it is followed under pressure.
Common mistakes
- SLIs that measure infrastructure rather than user experience: "CPU utilization" and "pod restarts" are operations metrics, not SLIs. SLIs must reflect what users experience: request success, latency, or data quality.
- SLOs set without stakeholder alignment: An SLO document signed off only by engineering will not produce the cross-functional behavior change needed; product and business stakeholders must co-own the targets.
- No error budget policy or unenforced policy: The error budget without a policy is a number, not a lever. Define the policy upfront and enforce it consistently — the first time the policy is overridden without justification, the framework loses its credibility.
- Reviewing SLOs only when something breaks: SLOs should be reviewed proactively on a cadence, not just reactively after incidents. Quarterly calibration prevents SLOs from drifting out of alignment with actual user expectations.
Review checklist
- Is each SLI directly observable from existing monitoring infrastructure, or is there a plan to build the measurement?
- Were SLO targets calibrated against at least 60–90 days of historical SLI data?
- Is the error budget policy documented, and has it been reviewed and approved by both engineering and product leadership?
- Are burn rate alerts configured in the monitoring system, linked to runbook sections?
- Is a quarterly SLO review meeting scheduled and a named owner assigned to maintain this document?
Example usage
- E-commerce checkout service: A team defines an availability SLO of 99.9% and a latency SLO of 95% of requests under 500ms. When a botched deployment consumes 60% of the monthly error budget in a single night, the error budget policy automatically freezes feature deployments and the team spends two weeks hardening the deployment pipeline with automated canary analysis.
- Data pipeline service: A data platform team defines a freshness SLO of 99.5% (data must be updated within 5 minutes). The SLO document drives the decision to invest in pipeline monitoring and automatic replay tooling, reducing the frequency of freshness SLO violations from weekly to monthly.
- Internal API platform: A platform engineering team publishes SLO documents for each shared API, enabling downstream service teams to set their own SLOs based on the platform's commitments, creating a coherent multi-tier reliability model across the organization.
Related templates
- Incident Postmortem — postmortems quantify error budget consumption; the SLO document defines the budget being consumed.
- Runbook — runbook procedures are triggered when SLO burn rate alerts fire; the SLO and runbook are operationally coupled.
- Reliability — SLOs are a core tool in site reliability engineering and reliability architecture.