Template Overview

Site reliability engineering relies on quantitative error budgets to balance feature release velocity against system stability. The Service Level Objective Review template guides SRE and infrastructure teams through monthly availability evaluations, error budget consumption analysis, and reliability remediation planning.

Markdown Template Structure

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

---
title: "SLO Review: [Service / Domain Name] - [Month / Year]"
date: [YYYY-MM-DD]
sre_lead: "[[Lead Site Reliability Engineer]]"
engineering_director: "[[Director of Infrastructure]]"
service_name: "[Core Ingestion / Auth / Sync Engine]"
error_budget_status: "Healthy / Exhausted / At Risk"
tags: [sre, slo, sli, reliability, devops, error-budget]
---

# Service Level Objective Review — [Service Name]

## 1. SLI Dashboard & Error Budget Health
| Objective (SLO) | Target SLA | Measured SLI (30 Days) | Error Budget Remaining | Status |
|---|---|---|---|---|
| **Availability** | 99.95% | 99.972% | 44% Remaining | Healthy |
| **p95 Search Latency** | < 15ms | 8.4ms | 100% Remaining | Healthy |
| **p99 Audio Transcription** | < 500ms chunk | 720ms chunk | 0% (Exhausted) | **Exhausted** |

## 2. Error Budget Consumption Events
- **Incident SEC-8492 (October 4):** 28 minutes of elevated p99 transcription latency due to CPU throttling during thermal saturation on low-memory Intel hardware.
- **Budget Burn Analysis:** The event consumed 78% of the monthly transcription latency error budget in a single 4-hour window.

## 3. Reliability vs Velocity Policy Enforcement
- **Policy Threshold Triggered:** Error budget for transcription latency is completely exhausted.
- **Mandatory Policy Action:** Feature development on audio transcription plugins is temporarily frozen; team must dedicate 100% of upcoming sprint capacity to Metal acceleration and memory pool optimizations.

## 4. Reliability Engineering Directives
- [ ] [[Lead SRE]] Implement dynamic audio downsampling fallback when CPU temperatures cross 85°C.
- [ ] [[Systems Engineer]] Optimize Metal Performance Shaders kernel routines to reduce GPU memory pressure.
- [ ] Re-evaluate transcription SLI metrics in two weeks to confirm error budget stabilization.

Filled Real-World Example

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

---
title: "SLO Review: Desktop Search Subsystem"
date: 2026-10-09
sre_lead: "[[Devin Zhao]]"
engineering_director: "[[Sarah Sterling]]"
service_name: "Local Search Subsystem"
error_budget_status: "Healthy"
tags: [sre, slo, sli, reliability, devops]
---

# Service Level Objective Review — Local Search Subsystem

## 1. Metric Overview
Devin Zhao reported that the local SQLite FTS5 search index operated with 100% availability and a p95 query latency of 6.2ms over the past 30 days, well within the 15ms target SLO.

## 2. Policy Consensus
With 92% of the error budget intact, Sarah Sterling confirmed the search engineering team is cleared to proceed with shipping advanced regex pattern matching features.

When to Use and When to Avoid

When to Use

  • Use during monthly or quarterly site reliability engineering reviews with engineering management.
  • Use when an error budget is depleted to enforce objective reliability engineering investments.
  • Use to establish transparent, data-driven availability benchmarks across all software services.

When to Avoid

  • Avoid using during active Sev-1 crisis triage (use incident command templates instead).
  • Avoid using for qualitative team culture discussions (use general retro templates).

On-Device AI Integration

Summarize your recording in Oyma with this local instruction:

Analyze the SLO review audio recording:
1. Tabulate all measured SLIs against target SLO benchmarks and calculate remaining error budgets.
2. Synthesize root causes for any major error budget consumption events discussed.
3. Document mandatory reliability directives, feature freeze enforcements, and engineering action items.
Output in clean, structured Markdown.

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

Frequently Asked Questions

What is the distinction between an SLI, an SLO, and an SLA?

An SLI is a service level indicator (actual measured metric), an SLO is a service level objective (internal reliability target), and an SLA is a service level agreement (contractual customer promise with penalties).

Why document SLO error budgets in Markdown notes?

Markdown notes provide a durable, human-readable record of reliability trends over time, easily shared across engineering and executive stakeholders.

Does Oyma keep sensitive server telemetry and uptime data secure?

Yes. Oyma runs locally on macOS with zero external telemetry, keeping infrastructure architecture details safe from third-party interception.