Operations
AuraScore 81/100

Production Outage Operational Postmortem Readiness Checklist

Evaluate incident mitigation, telemetry verification, and operational remediation items across engineering teams.

Use when engineering operations teams conclude a Tier-1 production incident and need an exhaustive verification checklist for root cause mitigation. It ensures systemic architectural risks and telemetry gaps are eliminated before closing the postmortem.

Template

Role: Principal Site Reliability Engineer and Infrastructure Operations Director

Context

  • Incident reference: {{incident_identifier}}
  • Core impacted architecture: {{affected_subsystems}}
  • Service Level Agreement threshold breached: {{sla_breach_threshold}}
  • Primary failure vector: {{root_cause_summary}}
  • Target deployment infrastructure: {{deployment_environment}}
  • Assigned engineering unit: {{remediation_owner_team}}

Task

Generate an exhaustive operational postmortem validation checklist that audits diagnostic telemetry, architectural regression tests, failover runbooks, and preventive controls to guarantee zero recurrence across the operational environment.

Method

  1. Inspect {{root_cause_summary}} against the baseline architecture of {{affected_subsystems}} to define mandatory containment boundary checks.
  2. Detail pre-incident telemetry gaps within {{deployment_environment}} that delayed root-cause detection past {{sla_breach_threshold}}.
  3. Establish infrastructure-level sanity verification items for all stateful and stateless dependencies.
  4. Design automated health probe and synthetic canary test checklists for {{affected_subsystems}}.
  5. Formulate actionable verification checkpoints for {{remediation_owner_team}} to enforce in continuous integration pipelines.
  6. Detail configuration drift and environment parity checks between staging and {{deployment_environment}}.
  7. Map explicit operational handoff validation criteria before incident {{incident_identifier}} is officially marked resolved.

Constraints

  • MUST express every checklist item as an actionable, imperative verification command with pass/fail criteria.
  • MUST organize checklist items chronologically from immediate telemetry remediation to long-term architectural hardening.
  • MUST NOT include vague advice or generic software engineering maxims.
  • Operational checklist must not exceed 25 total line items.

Output format

1. Incident Overview & Blast Radius Context

(Concise tabular summary of the failure mode, affected nodes, and SLA impact)

2. Immediate Infrastructure & Telemetry Remediation Checklist

(Numbered list of 6-8 operational verification checks with markdown checkboxes [ ])

3. Architectural Resilience & Automated Guardrail Checklist

(Numbered list of 6-8 deep technical checks with markdown checkboxes [ ])

4. Operational Sign-Off & Runbook Validation

(Numbered list of 4-6 verification steps required before closing postmortem)

Self-review

  • Confirm all 6 variables ({{incident_identifier}}, {{affected_subsystems}}, {{sla_breach_threshold}}, {{root_cause_summary}}, {{deployment_environment}}, {{remediation_owner_team}}) are addressed.
  • Ensure each checklist item specifies the exact mechanism for validation.
  • Verify no placeholders or unresolved markers exist in the generated checklist.
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.

business-strategy
business-operations
software-engineering-debugging
operations
sre
incident-management