Service Level Objective Spec

Template Overview

Striving for 100% uptime is an anti-pattern that paralyses engineering velocity and inflates infrastructure costs. Following Google Site Reliability Engineering (SRE) principles, the Service Level Objective (SLO) Spec defines measurable Service Level Indicators (SLIs), sets realistic reliability targets, calculates error budgets, and specifies burn-rate alerting triggers to balance product innovation with operational stability.

Markdown Template Structure

Copy the block below or click Download .md File to add this template directly to your personal vault:

---
title: "SLO Spec: [Service Name / Critical User Journey]"
date: [YYYY-MM-DD]
sre_lead: "[[SRE Lead Name]]"
service_tier: "[Tier 0 / Tier 1 / Tier 2]"
rolling_window_days: 30
target_slo_percent: 99.9%
error_budget_minutes_per_month: 43.2
tags: [sre, slo, sli, error-budget, observability, reliability, devops]
---

# Service Level Objective Spec — [Service Name]

## 1. Critical User Journey (CUJ) & Service Scope
- **Critical User Journey:** A user opens the desktop application, records an audio note, and successfully transcribes it into Markdown.
- **Service Boundary:** The local desktop binary executing on Apple Silicon unified memory.
- **Why This Matters:** If transcription fails, the user loses their meeting record, destroying core product utility.

## 2. Service Level Indicators (SLIs) Formulation
- **SLI 1 (Availability):** The proportion of valid recording sessions that complete without application crash or memory fault.
  - *Formula:* `Sum(Successful Recording Sessions) / Sum(Total Initiated Sessions) * 100`
- **SLI 2 (Latency):** The proportion of audio seconds transcribed at a Real-Time Factor (RTF) ≤ 0.25 (4x faster than real-time).
  - *Formula:* `Count(Transcriptions where RTF <= 0.25) / Count(Total Transcriptions) * 100`

## 3. SLO Targets & Error Budget Allocations
| Indicator | 30-Day SLO Target | Monthly Allowed Unreliability (Error Budget) | Primary Cause of Budget Consumption |
|---|---|---|---|
| Availability SLI | **99.9%** | 0.1% (~43.2 minutes downtime / ~1 in 1,000 sessions) | Unhandled audio hardware disconnects |
| Latency SLI | **99.0%** | 1.0% (~1 in 100 transcriptions) | Background thermal throttling on older M1 laptops |

## 4. Multi-Window Multi-Burn-Rate Alerting Rules
*Following Google SRE alert design to eliminate alert fatigue:*
- **Page Alert (Burn Rate 14.4x):** 2% of error budget consumed in 1 hour → PagerDuty triggers SRE page.
- **Ticket Alert (Burn Rate 6.0x):** 5% of error budget consumed in 6 hours → Jira high-priority bug filed.
- **Email Alert (Burn Rate 1.0x):** 10% of error budget consumed in 3 days → Weekly engineering review agenda.

## 5. Error Budget Policy & Operational Consequences
- **When Error Budget is Healthy (> 20% remaining):** Feature teams ship new experiments, major refactors, and aggressive canary flags.
- **When Error Budget is Exhausted (≤ 0% remaining):**
  - All feature deployments freeze immediately.
  - 100% of sprint capacity redirects toward bug fixes, memory profiling, and reliability hardening.
  - Feature freeze remains in effect until error budget recovers to > 20% over a 14-day rolling window.

Filled Real-World Example

Here is a realistic example demonstrating how this template captures actual deliberations:

---
title: "SLO Spec: On-Device Whisper Transcription Engine"
date: 2026-10-09
sre_lead: "[[David Chen]]"
service_tier: "Tier 0 Core"
rolling_window_days: 30
target_slo_percent: 99.95
error_budget_minutes_per_month: 21.6
tags: [sre, slo, sli, error-budget, observability, reliability, devops]
---

# Service Level Objective Spec — On-Device Whisper Transcription Engine

## 1. Scope
- Measures local transcription crash rate and real-time processing factor on Apple Silicon hardware.

## 2. SLIs & SLOs
- Availability SLO: 99.95% successful completions without crash.
- Latency SLO: 99.0% processed at RTF ≤ 0.20 (5x real-time speed).

## 3. Error Budget Policy
- If crash rate breaches 0.05%, automated release gating blocks all subsequent pull requests until stability is restored.

When to Use and When to Avoid

When to Use

• Use when defining production reliability standards for backend services, APIs, or client desktop software.
• Use to establish objective agreements between product managers pushing features and SREs protecting stability.
• Use to configure modern Prometheus / Datadog multi-window burn-rate alerts.

When to Avoid

• Avoid using for experimental prototypes where uptime expectations do not exist.
• Avoid using if you do not have the telemetry infrastructure to measure the indicator accurately.

On-Device AI Integration

Summarize your recording in Oyma with this local instruction:

Analyze the SLO specification:
1. Validate the mathematical formulation of the SLI to ensure it directly reflects user pain.
2. Check that the multi-window burn-rate alert triggers align with Google SRE workbook standards.
3. Draft a firm, balanced Error Budget Policy agreement between Product and Engineering leads.
Output in structured Markdown.

Your data remains securely on your Mac with zero cloud exposure.