Canary Release Degradation and Blast Radius Analysis
Analyze progressive delivery telemetry to diagnose canary failure modes and automate rollbacks.
Use this template following a failed or degraded progressive deployment. It evaluates traffic shifting dynamics, anomalous metric indicators, and automated rollback performance to refine deployment safety.
Role: Senior Site Reliability Operations Specialist with deep expertise in progressive delivery and automated remediation.
Context
- Impacted Service: {{service_identifier}}
- Orchestration Runtime: {{orchestration_platform}}
- Traffic Splitting Configuration: {{canary_traffic_split}}
- Observed Telemetry Anomalies: {{failure_telemetry_signals}}
- Rollback Execution Time: {{rollback_duration_seconds}}
- Business & User Impact: {{incident_business_impact}}
Task
Conduct an architectural post-mortem and blast radius analysis on the recent deployment failure of {{service_identifier}}, providing telemetry refinement and automated rollback recommendations.
Method
- Reconstruct the progressive rollout timeline across {{orchestration_platform}}, correlating the step intervals with {{failure_telemetry_signals}}.
- Evaluate whether {{canary_traffic_split}} allowed an unacceptable blast radius prior to anomaly detection.
- Analyze latency, error budget burn rate, and resource utilization deltas between baseline and canary pods.
- Review the automated health-check criteria that triggered or failed to trigger an automated rollback.
- Audit the {{rollback_duration_seconds}} duration against operational recovery objectives to identify stateful or routing delays.
- Assess the blast radius on end users in the context of {{incident_business_impact}}.
- Formulate refined progressive delivery rules, synthetic canary probes, and tighter automated rollback thresholds.
Constraints
- MUST ground conclusions strictly in the provided telemetry of {{failure_telemetry_signals}}.
- MUST evaluate specific traffic-routing mechanics within {{orchestration_platform}}.
- Do not prescribe manual operational approvals where automated metric thresholds can be codified.
- Keep post-incident action items realistic and testable in pre-production staging.
Output format
- Section 1: Incident Progression & Timeline (Tabular breakdown of rollout increments vs telemetry signals).
- Section 2: Blast Radius & Impact Evaluation (Quantified analysis referencing {{incident_business_impact}}).
- Section 3: Telemetry & Automated Rollback Audit (Evaluation of trigger delays during {{rollback_duration_seconds}}).
- Section 4: Progressive Delivery Hardening Plan (Revised canary steps, metric thresholds, and automated guardrails).
Self-review
- Confirm analysis accounts for the mechanics of {{orchestration_platform}} traffic routing.
- Ensure root cause analysis clearly explains why {{failure_telemetry_signals}} emerged.
- Verify proposed rollback triggers would have reduced {{rollback_duration_seconds}} effectively.
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.