Error Budget Burn and Root-Cause Blast Radius Reporting Framework
Establish a post-mortem reporting framework to evaluate error budget exhaustion, blast radius, and system safeguards.
Use this template following a major system outage or continuous error budget burn to produce an architectural incident report that isolates cascading failure modes and validates automated safeguards.
Role: Principal Distributed Systems Architect and Reliability Lead.
Context
- Target infrastructure cluster: {{architecture_cluster_env}}
- Quarterly error budget consumption rate: {{error_budget_burn_rate}}
- Failure domain subsystem: {{root_cause_subsystem}}
- Cumulative outage duration: {{outage_duration_minutes}}
- Core ingestion pipeline: {{data_pipeline_id}}
- Validated remediation commit: {{mitigation_commit_hash}}
Task
Author an error budget burn and root-cause blast radius reporting framework that enables distributed systems teams to analyze catastrophic outages, quantify system availability burn in {{architecture_cluster_env}}, and document structural safeguards.
Method
- Calculate systemic availability impact against SLOs based on {{outage_duration_minutes}} of downtime.
- Determine the multi-window burn rate accelerating {{error_budget_burn_rate}} across the cluster.
- Trace the cascading failure path originating within {{root_cause_subsystem}} through {{data_pipeline_id}}.
- Quantify downstream blast radius including dropped messages, dead-letter queue overflow, and state corruption.
- Validate that {{mitigation_commit_hash}} resolves underlying deadlock, race condition, or memory leak triggers.
- Formulate defensive architectural patterns such as circuit breakers, backpressure valves, and degraded mode fallbacks.
- Structure an executive and engineering post-mortem reporting protocol that translates system telemetry into reliability commitments.
Constraints
- MUST establish a timeline with sub-second granularity for the initial trigger event in {{root_cause_subsystem}}.
- MUST NOT classify human operator error as a primary root cause; reports must isolate systemic and architectural gaps.
- All financial or data-loss impact metrics MUST explicitly correlate to {{data_pipeline_id}} throughput.
- Output MUST contain actionable architectural changes that directly address the mechanism validated in {{mitigation_commit_hash}}.
Output format
- Incident Reliability Summary (max 100 words, including total availability loss).
- Timeline and Blast Radius Mapping (chronological table: Timestamp, System State, Subsystem Impact, Ingestion Loss).
- Architectural Vulnerability Deep-Dive (analysis of failure mechanisms in {{root_cause_subsystem}}).
- Reliability Action Plan & Guardrails (prioritized table: Action Item, Engineering Owner, Verification Metric).
Self-review
- Check that the timeline requirements explicitly forbid operator blame and enforce systemic root cause analysis.
- Verify that {{architecture_cluster_env}} and {{mitigation_commit_hash}} are embedded in the remediation criteria.
- Ensure the output strictly follows the four numbered sections without omitting the blast radius mapping table.
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.