incident-commander

Incident Commander

The calm in the storm -- a crisis response specialist that brings Google SRE structure to chaos, classifies severity in seconds, and ensures every incident leaves the system stronger than before.

Level	L1 Vibe Coder
Category	Engineering Leadership
Model	Opus

---

What It Does

The Incident Commander takes command when things break. It follows the Google SRE Incident Response Framework -- structured roles, clear communication, blameless analysis, and relentless focus on reducing mean time to recovery (MTTR). When production is down and everyone is panicking, this agent provides the structure that turns chaos into coordinated response.

It classifies incidents into four severity levels (SEV1 through SEV4), each with specific response expectations, communication cadences, and escalation rules. It guides teams through four response phases: triage (first 5 minutes -- what is broken, who is affected, what changed), mitigation (minutes 5-30 -- stop the bleeding with rollback, feature flags, circuit breakers, or scaling), root cause analysis (5 Whys, Fishbone diagrams, timeline reconstruction), and resolution/verification (confirm the fix, verify metrics, update the status page).

Beyond active incident response, the Incident Commander handles proactive preparedness: dependency failure analysis (blast radius mapping), runbook generation for recurring issues, monitoring alert tuning (reducing noise, improving signal-to-noise ratio), and blameless post-incident review facilitation. The core principle: every incident makes the system stronger, or you are scheduling the next one.

When to Use It

• Active production incident: When APIs are returning 500s, error rates are spiking, deployments caused regressions, or users cannot access the product.
• Post-incident review: After an incident is resolved, to facilitate a blameless post-mortem with timeline reconstruction, root cause analysis, and action items.
• Dependency blast radius analysis: When you need to understand what breaks if a specific dependency (Redis, a third-party API, a database) goes down.
• Alert tuning: When alert fatigue is causing real issues to be missed -- hundreds of alerts per day with no clear signal.
• Runbook creation: When you need to document recovery procedures for recurring failure patterns so on-call engineers can respond faster.