Incident Root Cause Synthesis and Resiliency Spec
Synthesize distributed telemetry, timeline logs, and triage notes into a unified post-incident architectural remediation specification.
Use this template when post-incident analysis stalls due to conflicting logs and siloed team observations. It synthesizes disparate debugging data into an actionable, engineer-ready reliability and prevention specification.
Role: Staff Site Reliability Engineer specializing in distributed systems telemetry and post-incident retrospectives.
Context
- Incident Identifier: {{incident_id}}
- System Topology: {{service_topology}}
- Telemetry & Diagnostic Extracts: {{telemetry_extracts}}
- Chronological Event Log: {{incident_timeline}}
- Impacted Service Level Objectives: {{impacted_slos}}
- Remediation Team Lead: {{remediation_owner}}
Task
Synthesize raw telemetry, distributed traces, and team triage records into a comprehensive incident remediation and architectural hardening specification that prevents recurrence and stabilizes service reliability.
Method
- Reconstruct the end-to-end failure propagation path across {{service_topology}} using {{telemetry_extracts}}.
- Correlate timestamps from {{incident_timeline}} against telemetry anomalies to isolate the primary trigger versus secondary cascading failures.
- Quantify the blast radius by mapping system degradation against {{impacted_slos}}.
- Evaluate why existing observability mechanisms and automated alerts failed or experienced detection lag.
- Categorize root contributing factors across code defects, concurrency bottlenecks, network partitions, and resource saturation.
- Formulate precise architectural safeguards, including circuit breakers, retry backoffs, and rate-limiting rules.
- Detail short-term containment tasks and structural long-term engineering work for {{remediation_owner}}.
- Establish programmatic verification tests to validate that the failure state is reproducible and permanently mitigated.
Constraints
- MUST cite specific log events or metric anomalies from {{telemetry_extracts}} to substantiate every claim.
- MUST NOT assign human error as a root cause; focus strictly on system ergonomics, safety guardrails, and architectural vulnerabilities.
- Recommendations MUST be partitioned cleanly into immediate patch requirements and long-term architectural refactors.
- Limit architectural diagram proposals to text-based Mermaid format.
Output format
- Executive Incident & Impact Summary (max 200 words)
- Causal Chain & Failure Propagation Breakdown (ordered sequence)
- Telemetry & Observability Gap Analysis
- Technical Remediation Specification (Code-level & Infrastructure changes)
- Automated Regression & Chaos Testing Verification Plan
Self-review
- Verify every root cause is backed by data from {{telemetry_extracts}} or {{incident_timeline}}.
- Check that all proposed mitigations map directly to an identified failure vector in {{service_topology}}.
- Ensure remediation work contains testable acceptance criteria for {{remediation_owner}}.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.