Ship and Sustain a Reliable Service

Proof required

Submit an SLO definition document covering at least two services, with for each: the SLI definition (what is measured and how), the SLO target (percentage and time window), the error budget calculation, and the current actual SLI value from 30–90 days of historical monitoring data. Include a brief error budget report showing consumption rate and projected budget exhaustion timeline if current trends continue. ADVERSARIAL VERIFICATION: a named SRE, platform engineer, or engineering director (5+ years experience) must read the SLO definitions and provide written feedback confirming that the SLIs are meaningful user-experience proxies and not gaming-prone internal metrics.

What gets checked

• SLO definitions for ≥2 services, each with SLI, target, error budget, and actual baseline measurement
• Error budget report showing consumption rate from real monitoring data — not hypothetical values
• Reviewer feedback confirming SLIs are genuine user-experience proxies

Common mistakes

• Defining SLIs that measure internal system health (CPU utilisation, memory) rather than user-facing behaviour (request success rate, latency p99) — an SLO that measures CPU will not detect service degradation that matters to users
• Setting SLO targets that are already being met comfortably — an SLO with zero error budget consumption provides no signal about where to invest reliability effort; targets should reflect a meaningful reliability goal, not a current baseline
• Not using real monitoring data and estimating baseline values — estimated SLI baselines cannot be verified; the proof requires actual historical data from a monitoring system

Resources

What a verifier looks for

• SLIs must measure user-facing behaviour — ask the submitter to explain what a user experiences when the SLI drops below target; if they cannot, the SLI is likely an internal metric
• Baseline values must come from real monitoring data — ask for the monitoring system and the query or dashboard used to derive them
• The confirming reviewer must have SRE or platform engineering experience — a product manager cannot evaluate whether an SLI is a meaningful user-experience proxy

You'll sign in first, then come straight back here.

Proof required

Submit a reliability improvement report covering: (1) the top two error budget contributors identified from M1 data; (2) the two improvements implemented, with implementation evidence (code change, configuration, architectural diagram, or runbook update); (3) error budget consumption measurements from ≥4 weeks after implementation, compared to the M1 baseline. ADVERSARIAL VERIFICATION: your named SRE reviewer reads the improvement design before implementation and provides written feedback on whether the improvements are likely to reduce error budget consumption in the specific failure modes identified.

What gets checked

• Top two error budget contributors identified with supporting data from M1 monitoring
• Two improvements implemented with implementation evidence (not just planned)
• Error budget measurements from ≥4 weeks post-implementation compared to M1 baseline

Common mistakes

• Implementing reliability improvements without first identifying the error budget contributors — fixing the wrong failure modes leaves the SLO gap unchanged; start from the data, not from the improvements you already know how to make
• Making infrastructure changes and declaring improved reliability before running under real traffic conditions for at least 4 weeks — a canary deploy that is never promoted, or a circuit breaker that never fires, provides no reliability evidence
• Not distinguishing between a reduction in incident frequency and a reduction in error budget consumption — fewer incidents that each burn 1% error budget is the same as the original budget consumption; measure the budget, not just the count

Resources

What a verifier looks for

• Implementation evidence must show code or configuration changes — an architectural diagram without code or config is not implementation evidence
• Error budget measurements must be from the same monitoring system as M1 — changing the measurement approach between baseline and improvement makes the comparison unreliable
• The reviewer's pre-implementation feedback is the primary adversarial check — the question is whether the proposed improvements will move error budget consumption in the right direction

You'll sign in first, then come straight back here.

Proof required

Submit your service reliability improvement report and a record of the challenge session: names and professional roles of both panellists, date and duration (≥30 minutes), and notes on at least three challenges posed and your responses. A written statement from the primary SRE reviewer (50+ words) confirming that the SLO definitions are sound and the reliability improvements are causally linked to error budget recovery. ADVERSARIAL VERIFICATION RULE Level 2: live session required.

What gets checked

• Service reliability improvement report: SLO definitions + baseline + improvements + results
• Challenge session with ≥2 SRE/infrastructure panellists, duration ≥30 minutes, ≥3 challenges documented
• Written statement from primary SRE reviewer (50+ words) confirming sound SLOs and causal improvement linkage

Common mistakes

• Presenting error budget improvements without showing the underlying monitoring data — SRE panellists will ask to see the dashboard or query, not just the summary numbers
• Claiming causality without controlling for external factors — if error budget improved during a period of reduced traffic or fewer deployments, that is a confounder the panel will identify
• Presenting to a panel that lacks SRE experience — product managers and scrum masters cannot provide the adversarial challenge required by ADVERSARIAL VERIFICATION RULE Level 2 for this outcome

Resources

What a verifier looks for

• Both panellists must have direct SRE or infrastructure engineering experience — confirm their professional roles before accepting the session record
• ADVERSARIAL VERIFICATION RULE Level 2 requires a live synchronous session of ≥30 minutes
• The reviewer statement must confirm both SLO soundness and causal linkage — a statement that only confirms 'the process was followed' without evaluating the SLO design or the causal claim is insufficient

You'll sign in first, then come straight back here.