SLO Reporting & Reviews

Why Report on SLOs?

SLO data is only useful if people see it. Regular reporting makes reliability visible to engineering, product, and leadership. It surfaces trends before they become incidents and builds a shared understanding of service health across the organization.

Report Contents

A good SLO report includes current status, historical trends, budget consumption, and notable events. Keep it concise — leadership wants a summary, not raw data.

1. Current SLI values and SLO targets for each service
2. Error budget remaining (percentage and time estimate)
3. Burn rate trend over the last 30 days
4. Notable incidents that consumed significant budget
5. Deployments or changes that affected reliability
6. Upcoming risks (major releases, infrastructure changes)
7. Action items from previous review

Stakeholder Audience

Different stakeholders need different levels of detail. Engineers need raw metrics and alert history. Product managers need budget status and feature impact. Leadership needs trends and business risk.

Trend Analysis

Trends matter more than snapshots. A service at 99.95% with a declining trend needs attention even though it is above its 99.9% SLO. A service at 99.85% with an improving trend may not need intervention. Track direction, not just current state.

groups:
  - name: slo_trends
    interval: 1h
    rules:
      # 7-day average vs 30-day average
      - record: slo:trend:comparison
        expr: |
          (
            avg_over_time(slo:http_availability:ratio_rate30d[7d])
            -
            avg_over_time(slo:http_availability:ratio_rate30d[30d])
          )

      # Trending up = positive, trending down = negative
      - record: slo:trend:direction
        expr: |
          slo:trend:comparison > 0.001
          or
          slo:trend:comparison < -0.001

Automating Reports

Manual reports are slow and error-prone. Automate SLO reporting with scheduled queries, templated documents, and automatic distribution. Use Prometheus recording rules to pre-compute the data your reports need.

#!/usr/bin/env bash
# Generate monthly SLO report

PROMETHEUS_URL="http://prometheus.internal:9090"
REPORT_DATE=$(date +%Y-%m)
OUTPUT="slo-report-$REPORT_DATE.md"

cat > "$OUTPUT" << EOF
# SLO Report - $REPORT_DATE

## Service: user-api

### Availability
- SLO Target: 99.9%
- Current (30d): $(curl -s "$PROMETHEUS_URL/api/v1/query?query=slo:http_availability:ratio_rate30d" | jq '.data.result[0].value[1]')
- Budget Remaining: $(curl -s "$PROMETHEUS_URL/api/v1/query?query=error_budget:remaining" | jq '.data.result[0].value[1]')

### Latency
- SLO Target: p99 < 200ms
- Current (30d): $(curl -s "$PROMETHEUS_URL/api/v1/query?query=sli:http_latency_seconds:p99" | jq '.data.result[0].value[1]')s

### Incidents This Month
$(curl -s "$PROMETHEUS_URL/api/v1/query?query=count(increase(http_request_duration_seconds_count{code=~'5..'}[30d]))" | jq '.data.result[0].value[1]') error spikes detected
EOF

echo "Report generated: $OUTPUT"

Review Meetings

Monthly SLO review meetings bring engineering and product together to discuss reliability. Keep them short (30 minutes) and focused. Review the report, discuss trends, and assign action items. End with a decision: maintain current SLOs or adjust targets.