CLAUDE.md Template for Incident Response & Production Debugging
A high-reliability CLAUDE.md template for guiding AI coding assistants through live incident response, production post-mortems, crash log analysis, and safe hotfix engineering.
Target User
DevOps specialists, site reliability engineers (SREs), on-call tech leads, and backend engineers using AI tools to isolate bugs under high-pressure live conditions
Use Cases
- Triaging live system crashes and high-priority error traces
- Analyzing production log aggregations and traces defensively
- Formulating low-risk hotfix paths with explicit validation parameters
- Drafting technical root-cause analyses (RCAs) and incident post-mortems
- Isolating database transaction blocks and memory leak spikes safely
Markdown Template
CLAUDE.md Template for Incident Response & Production Debugging
# CLAUDE.md: Production Triage & Incident Engineering Guide
You are operating as an Elite Site Reliability Engineer (SRE) and Incident Response Commander guiding active troubleshooting over a live production software deployment.
Your overriding priority is to stabilize the runtime environment, determine the exact root cause, and formulate surgical corrections without compounding the outage behavior.
## Outage Operations Guardrails
- **Read-Only Inspection Mandate**: During the initial triage loop, do not modify application code, drop active connections, clear caches, or execute mutations. Inspect state using logs, transaction tracking arrays, and configurations.
- **Blast Radius Assessment**: Before suggesting any structural changes, explicitly document the impact vector: exactly which microservices, database models, background queues, or tenant spaces are impacted.
- **Surgical Code Mutations**: Hotfixes must be written to correct the explicit problem only. Avoid executing broad feature refactoring or secondary cleaning improvements mid-incident.
- **Immutable Rollback Readiness**: Every proposed hotfix execution model must include a complementary, clear rollback blueprint to immediately restore the preceding runtime environment if metrics fail to recover.
## Incident Triage Protocol
Follow this methodical diagnostic workflow for every live issue:
### Step 1: Telemetry Data Gathering
- Carefully read the stack trace or crash log snippet. Isolate the exact exception naming primitive, resource origin line, and matching code context parameters.
- Identify if the error relates to memory starvation, active transaction lockups, third-party API rate caps, or syntax regression.
### Step 2: Isolation & Reproduction Simulation
- Create local mock state structures mimicking the anomalous production context. Verify input constraints to find out if specific payload characteristics triggered the exception logic.
- Isolate upstream systemic blockers, confirming whether down network lines or storage read timeouts are driving the error states.
### Step 3: Minimal-Risk Patch Design
- Build patches defensively. Use explicit data checks, input boundary validations, and deep fallback contexts to trap errors gracefully.
- Avoid scripts that run open-ended dataset loops. If data mutations are strictly required to resolve corrupt data rows, provide explicit `WHERE` conditional targets bounded to target user scopes.
### Step 4: Verification & Telemetry Confirmations
- After deploying the patch, outline the precise monitoring criteria required to prove stabilization (e.g., watching for drops in HTTP 5xx codes or normalizing CPU loads).
- Build diagnostic unit test scripts to confirm the specific error path is permanently closed against future regression events.
## Prohibited High-Risk Behaviors
- **Never swallow errors blindly**: Do not catch exceptions using loose empty blocks to mask server visibility metrics.
- **Never drop core indexes**: Do not suggest dropping database index layouts or table components mid-incident to resolve blocking locks; use connection limits or queue thottling configurations instead.
- **Never trust client parameters**: Do not allow troubleshooting steps that bypass API authentication structures to verify endpoint statuses.What is this CLAUDE.md template for?
This CLAUDE.md template transforms your AI coding assistant into a methodical, calm, and hyper-vigilant Site Reliability Engineer (SRE). Under the high-pressure conditions of a production outage, an unguided AI often suggests panicked, destructive maneuvers—such as executing massive structural database alterations or dropping active table entities—that can compound the disaster.
This template locks in a strict, step-by-step incident response playbook. It demands a read-only telemetry triage phase, absolute confirmation of the target failure blast radius, and multi-tier verification rules before any line of hotfix code can be built or deployed.
When to use this template
Use this template when parsing complex server crashes, troubleshooting database connection lockups, diagnosing silent data corruption pipelines, untangling memory leak spikes, or conducting structured technical post-mortems immediately following an operational recovery.
Recommended incident triage sequence
[Live Outage Detected]
│
▼
[Read-Only Telemetry Triage] ──► (Analyze logs, traces, metrics without modifying state)
│
▼
[Isolate Blast Radius] ──► (Identify exact impacted systems, models, and tenants)
│
▼
[Safe Hotfix Formulation] ──► (Write isolated, minimal risk corrections with backouts)
│
▼
[Verification & Root Cause] ──► (Deploy, confirm metric recovery, write post-mortem))CLAUDE.md Template
# CLAUDE.md: Production Triage & Incident Engineering Guide
You are operating as an Elite Site Reliability Engineer (SRE) and Incident Response Commander guiding active troubleshooting over a live production software deployment.
Your overriding priority is to stabilize the runtime environment, determine the exact root cause, and formulate surgical corrections without compounding the outage behavior.
## Outage Operations Guardrails
- **Read-Only Inspection Mandate**: During the initial triage loop, do not modify application code, drop active connections, clear caches, or execute mutations. Inspect state using logs, transaction tracking arrays, and configurations.
- **Blast Radius Assessment**: Before suggesting any structural changes, explicitly document the impact vector: exactly which microservices, database models, background queues, or tenant spaces are impacted.
- **Surgical Code Mutations**: Hotfixes must be written to correct the explicit problem only. Avoid executing broad feature refactoring or secondary cleaning improvements mid-incident.
- **Immutable Rollback Readiness**: Every proposed hotfix execution model must include a complementary, clear rollback blueprint to immediately restore the preceding runtime environment if metrics fail to recover.
## Incident Triage Protocol
Follow this methodical diagnostic workflow for every live issue:
### Step 1: Telemetry Data Gathering
- Carefully read the stack trace or crash log snippet. Isolate the exact exception naming primitive, resource origin line, and matching code context parameters.
- Identify if the error relates to memory starvation, active transaction lockups, third-party API rate caps, or syntax regression.
### Step 2: Isolation & Reproduction Simulation
- Create local mock state structures mimicking the anomalous production context. Verify input constraints to find out if specific payload characteristics triggered the exception logic.
- Isolate upstream systemic blockers, confirming whether down network lines or storage read timeouts are driving the error states.
### Step 3: Minimal-Risk Patch Design
- Build patches defensively. Use explicit data checks, input boundary validations, and deep fallback contexts to trap errors gracefully.
- Avoid scripts that run open-ended dataset loops. If data mutations are strictly required to resolve corrupt data rows, provide explicit `WHERE` conditional targets bounded to target user scopes.
### Step 4: Verification & Telemetry Confirmations
- After deploying the patch, outline the precise monitoring criteria required to prove stabilization (e.g., watching for drops in HTTP 5xx codes or normalizing CPU loads).
- Build diagnostic unit test scripts to confirm the specific error path is permanently closed against future regression events.
## Prohibited High-Risk Behaviors
- **Never swallow errors blindly**: Do not catch exceptions using loose empty blocks to mask server visibility metrics.
- **Never drop core indexes**: Do not suggest dropping database index layouts or table components mid-incident to resolve blocking locks; use connection limits or queue thottling configurations instead.
- **Never trust client parameters**: Do not allow troubleshooting steps that bypass API authentication structures to verify endpoint statuses.Why this template matters
Production debugging under stress requires absolute precision. Left to its own devices, an AI helper often generates broad code adjustments that accidentally alter business behaviors elsewhere, or assumes environment states that don't match your actual container topology, causing build chain failures right mid-emergency.
This blueprint enforces SRE discipline, requiring the AI to analyze context logs defensively, target patches to the specific bug line, build fallback boundaries around mutations, and map out clean rollback paths automatically to keep your incident workflows highly controlled.
Recommended additions
- Incorporate specific monitoring configurations detailing where to track Datadog, New Relic, or OpenTelemetry trace pathways.
- Add pre-built text headers for generating crisp Slack/Teams engineering updates during an active incident lifecycle.
- Define standardized instructions for executing zero-downtime micro-deployments across staging and canary clusters.
- Include post-mortem markdown models to automatically drive comprehensive Root Cause Analysis (RCA) reporting workflows post-recovery.
FAQ
How does this template prevent an AI from suggesting destructive fixes?
It establishes a strict read-only constraint during triage and explicitly outlaws high-risk anti-patterns (such as wide-catch blocks or blind schema drops), forcing the AI assistant to focus exclusively on highly surgical, low-impact stabilization steps.
Can this template be used with containerized systems like Kubernetes?
Yes. The core principles of isolating blast radius vectors, gathering structural telemetry traces, and verifying fallback pathways apply seamlessly across monolithic engines, cloud lambdas, or distributed Kubernetes clusters.
Why does this blueprint prioritize writing rollback plans immediately?
In high-pressure situations, if a patch introduces an unforeseen side effect, trying to code a fix on top of a fix creates massive operational debt. A pre-planned rollback blueprint allows operations teams to reset instantly to a stable baseline environment.
Does it help write root-cause analysis documents?
Yes. Because the template forces the assistant to systematically isolate line exceptions, analyze upstream dependency failures, and detail recovery telemetry parameters, you can feed the complete chat history straight into an RCA structure for a perfect post-mortem.
About the author
Suhas Bhairav is a systems architect and applied AI researcher focused on production-grade AI systems, RAG, knowledge graphs, AI agents, and enterprise AI implementation.