Docs & technical writing
AuraScore 81/100

Production Incident Root Cause Analysis Brief

Draft a post-incident technical brief documenting root triggers, blast radius, recovery timelines, and remediation items.

Use this template following critical service outages or severe system degradations. It turns complex logs, triage actions, and telemetry data into an actionable postmortem brief for engineering leadership.

Template

Role: Senior Site Reliability Engineering Technical Documentarian

Context

  • Incident Identifier: {{incident_id}}
  • Affected Subsystems: {{affected_subsystems}}
  • Outage Duration: {{outage_duration}}
  • Root Trigger: {{root_trigger}}
  • Recovery Procedure: {{recovery_procedure}}
  • Preventative Actions: {{preventative_actions}}

Task

Compile a concise, blameless Root Cause Analysis (RCA) documentation brief summarizing the timeline, system dynamics, recovery actions, and preventative roadmap for {{incident_id}}.

Method

  1. Establish the operational timeline from first anomaly detection to complete remediation for {{incident_id}}.
  2. Isolate the failure propagation chain, mapping how {{root_trigger}} cascaded through {{affected_subsystems}}.
  3. Quantify total system degradation across {{outage_duration}}, including dropped requests, error rates, and degraded SLAs.
  4. Document the exact technical remediation steps enacted during {{recovery_procedure}}.
  5. Evaluate telemetry blind spots or delayed monitoring signals that lengthened the time to detect (TTD) or mitigate (TTM).
  6. Categorize human, architectural, and tooling vulnerabilities exposed during the incident.
  7. Convert {{preventative_actions}} into prioritized, actionable engineering tickets with defined owners.
  8. Formulate a blameless narrative detailing failure resilience lessons learned.

Constraints

  • MUST adhere to strict blameless postmortem writing standards; focus purely on systemic conditions.
  • MUST NOT omit exact timestamps or chronological order in the incident timeline section.
  • Every action item in {{preventative_actions}} must be categorized by Priority (P0, P1, P2).
  • Technical explanations must be reproducible based on logged system telemetry.
  • Total word count must not exceed 650 words.

Output format

Structure the brief strictly into the following sections:

  1. Incident Metadata & Executive Summary (Max 80 words)
  2. Chronological Triage & Recovery Timeline (Timestamped bullet points spanning {{outage_duration}})
  3. Root Cause & Propagation Mechanism (Detailed technical description of {{root_trigger}})
  4. Recovery Validation (Summary of {{recovery_procedure}} verification)
  5. Remediation Action Matrix (Table containing Priority, Action Item, Subsystem, and Prevention Target)

Self-review

  • Ensure no individual engineer or operator is blamed in the narrative.
  • Confirm that {{root_trigger}} logically accounts for all symptoms in {{affected_subsystems}}.
  • Check that all {{preventative_actions}} are directly tied to eliminating recurrence.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

writing-content
writing-docs
software-engineering-debugging
incident-response
sre
postmortem