mcpField
I
incident-response

incident-response

github.com/nickcrewCloud & DevOps6265 installsUpdated 18w ago
Repository

About incident-response

Incident Response is a structured guide for teams handling production incidents and improving operational resilience. It covers detection, triage, containment, resolution, and blameless postmortems, with severity guidance and response practices.

Key features

  1. 01Guide incidents from detection to postmortem
  2. 02Classify severity and scope of impact
  3. 03Contain cascading failures with resilience patterns
  4. 04Coordinate communications and status updates
  5. 05Document timelines and assign follow-up actions

Use cases

  1. 01Respond to production outages or data loss
  2. 02Plan circuit breakers and fallback strategies
  3. 03Run chaos engineering exercises
  4. 04Write or review incident postmortems

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/nickcrew/claude-cortex --skill incident-response

After installing, type/incident-responsein Claude Code to confirm it loaded.

Bundled filesreferences/postmortem-patterns.mdreferences/triage-framework.md

Details

From the project README

Incident Response

Structured incident management from detection through postmortem, with resilience patterns for preventing and containing cascading failures.

When to Use

  • Production incident in progress (outage, degradation, data loss)
  • Designing circuit breakers, bulkheads, or fallback strategies
  • Conducting or planning chaos engineering exercises
  • Writing or reviewing postmortem documents
  • Establishing on-call procedures and escalation paths

Avoid when:

  • The issue is a development-time bug with no production impact
  • Designing general system architecture (use system-design instead)

Quick Reference

TopicLoad reference
Triage Frameworkskills/incident-response/references/triage-framework.md
Postmortem Patternsskills/incident-response/references/postmortem-patterns.md

Incident Response Workflow

Phase 1: Detect
  • Alert fires or user report received
  • Confirm the issue is real (not a false positive)
  • Identify affected services and user impact scope
Phase 2: Triage
  • Classify severity (P0-P3)
  • Assign incident commander
  • Open communication channel (war room, Slack channel)
  • Begin status page updates
Phase 3: Contain
  • Stop the bleeding: rollback, feature flag, traffic shift
  • Prevent cascade: circuit breakers, load shedding, bulkhead isolation
  • Communicate: stakeholder updates every 15 minutes for P0/P1
Phase 4: Resolve
  • Implement fix (minimal viable fix first)
  • Validate in staging if time permits
  • Deploy with monitoring and rollback plan ready
  • Confirm recovery with metrics returning to baseline
Phase 5: Postmortem
  • Document timeline within 48 hours
  • Conduct blameless review with all participants
  • Identify root cause and contributing factors
  • Assign action items with owners and deadlines
  • Update runbooks and alerting based on lessons learned

Severity Framework

LevelImpactResponse TimeExamples
P0Complete outage, data loss, security breachImmediate (< 5 min)Service down, data corruption, credential leak
P1Major feature broken, significant user impact< 30 minPayment processing failed, auth broken for region
P2Degraded performance, partial feature loss< 4 hoursElevated latency, non-critical feature unavailable
P3Minor issue, workaround availableNext business dayUI glitch, slow report generation, cosmetic error

Output

  • Incident timeline and severity classification
  • Containment actions taken
  • Postmortem document with action items
  • Updated runbooks and alerting rules

Common Mistakes

  • Skipping severity classification and treating everything as P0
  • Making changes without a rollback plan
  • Forgetting to communicate status to stakeholders
  • Writing postmortems that assign blame instead of identifying systemic issues
  • Not following up on postmortem action items

Comments

Markdown supported