Milestone map
Milestone map
3 milestones
Define SLOs and measure current reliability baseline
3 weeks
Define Service Level Objectives (SLOs) for at least two critical user-facing services — specifying the SLI (what is being measured), the SLO target (e.g. 99.9% availability over a 30-day rolling window), and the error budget derived from it. Measure the current reliability baseline by computing actual SLI values over the past 30–90 days using existing monitoring data. Produce an error budget report showing current error budget consumption and the reliability gap between actual and target.
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
Resources
Foundationstart here
Depthgo deeper
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
- 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
Implement reliability improvements and demonstrate error budget recovery
6 weeks
Identify the top contributors to error budget consumption from the M1 baseline and implement at least two reliability improvements targeting those contributors. Improvements may include: fixing the root cause of a recurring failure mode, improving alerting to catch degradation earlier, adding circuit breakers or retry logic, improving deployment safety (canary deploys, feature flags), or adding capacity to prevent saturation. Run the improvements for at least 4 weeks and measure the resulting error budget consumption compared to the M1 baseline.
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
Resources
Foundationstart here
Depthgo deeper
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
- 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
Present reliability improvement case with SRE challenge panel
2 weeks
Compile a service reliability improvement report covering SLO definitions, baseline measurements, improvement implementations, and post-improvement error budget results. Present the report in a live session of at least 30 minutes to a panel including your named SRE reviewer plus at least one additional SRE, infrastructure lead, or engineering manager. The panel challenges your SLI design choices, error budget calculations, and causal attribution of reliability improvements.
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
Resources
Foundationstart here
Depthgo deeper
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
- 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