Lead Incidents From Alert to Resolution

Proof required

Submit an incident response audit report of at least 500 words covering: current process documentation (detection, triage, escalation, resolution, review steps); baseline metrics for MTTD and MTTR (measured or estimated from historical incident records); post-mortem completion rate; and at least three specific named failure modes identified from at least five historical incidents. ADVERSARIAL VERIFICATION: a named Site Reliability Engineer (SRE), DevOps engineer, or infrastructure engineering lead (5+ years experience) must read the audit and provide written confirmation that the failure modes are substantive process breakdowns, not surface-level observations.

What gets checked

• 500-word audit with documented process, baseline MTTD/MTTR, post-mortem rate, and ≥3 failure modes from ≥5 historical incidents
• Failure modes are specific to your process — not generic statements that apply to any organisation
• Written confirmation from a named SRE/DevOps/infrastructure lead (5+ years) that the failure modes are substantive

Common mistakes

• Using only documentation to understand the process rather than reviewing real incident records — documented incident response processes routinely diverge from what actually happens during incidents; the audit must review real incidents
• Identifying generic industry failure modes ('we lack observability') without connecting them to specific gaps in your incidents — each failure mode must be evidenced by at least one named incident type or pattern
• Not measuring MTTR because exact data is unavailable — approximate values derived from incident records or engineering team memory are acceptable; absence of any measurement leaves the baseline undefined

Resources

What a verifier looks for

• The audit must reference real incidents — ask the submitter to name at least two of the five incidents reviewed (approximate dates and incident type are sufficient, not PII)
• Failure modes must be mechanistic — each failure mode should identify the specific step in the process that breaks and why; 'our on-call response is slow' is a symptom, 'on-call engineers are not paged until a human notices the alert, averaging 22 minutes post-incident start' is a failure mode
• The confirming reviewer must have direct SRE or incident response experience — a product manager or general engineering manager without infrastructure responsibility does not satisfy the 5+ years SRE/DevOps requirement

Proof required

Submit an incident response improvement report covering: (1) two improvements implemented with their target failure modes; (2) evidence of implementation (alerting configuration screenshots, updated runbook, post-mortem template, game day report, or equivalent); (3) updated MTTD/MTTR measurements from at least 4 weeks of operation after the improvements, compared to the M1 baseline. ADVERSARIAL VERIFICATION: your named SRE/DevOps reviewer reads the improvement design before implementation and provides written feedback on whether the improvements are likely to move the MTTD/MTTR metrics, or whether they primarily improve documentation without addressing the detection/response mechanism.

What gets checked

• Two improvements implemented with implementation evidence — not just designed on paper
• MTTD/MTTR measurements from ≥4 weeks post-improvement compared to M1 baseline
• Reviewer feedback on the improvement design before implementation confirming the changes target the detection/response mechanism

Common mistakes

• Improving documentation (runbooks, playbooks) without improving the detection or escalation mechanism — better documentation helps responders once paged; it does not reduce MTTD, which is the detection problem
• Not measuring after 4 weeks because no major incidents occurred — MTTD and MTTR can be measured on any incident type; document your measurements even if incident count is low
• Measuring MTTR only on resolved incidents and excluding incidents that required multiple responders or cross-team escalation — complex incidents are where MTTR failures are most visible and most important to measure

Resources

What a verifier looks for

• Implementation evidence must be specific — a screenshot of a new PagerDuty alert rule, a link to the updated runbook in a wiki, or the completed post-mortem template are all acceptable; 'we updated our process' is not
• Post-improvement MTTD/MTTR must be compared to the M1 baseline — if no change is observable, that is a valid result that should prompt discussion about why
• The reviewer's pre-implementation feedback is the core check — the question is whether the improvements target MTTD (detection) or MTTR (response), not both simultaneously

Proof required

Submit your incident response 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 improvements represent genuine changes to detection or response capability. ADVERSARIAL VERIFICATION RULE Level 2: live session required.

What gets checked

• Incident response improvement report: M1 audit + M2 results + reliability roadmap recommendations
• Challenge session record with ≥2 named panellists (both with SRE/infrastructure experience), duration ≥30 minutes, ≥3 challenges documented
• Written statement from primary SRE reviewer (50+ words) confirming genuine capability improvements

Common mistakes

• Presenting MTTD/MTTR improvements without the underlying incident data — good SRE panellists will ask to see sample incident records to validate the metric calculations
• Attributing MTTD/MTTR changes to your improvements when other confounding changes occurred in the same period (infrastructure migration, team growth, technology change) — identify and acknowledge confounders explicitly
• Choosing a panel without direct SRE or reliability engineering experience — a product manager and a general engineering manager cannot provide the adversarial challenge that an SRE or infrastructure lead can

Resources

What a verifier looks for

• Both panellists must have direct SRE or infrastructure engineering experience — check professional roles before accepting the session record
• ADVERSARIAL VERIFICATION RULE Level 2 requires a live synchronous session — async written questions do not qualify
• The reviewer statement must confirm capability changes — 'the team now detects incidents faster because…' or 'the post-mortem process now produces…' are the types of claims that satisfy the requirement