Live Outage Incident Command
Run a live outage: impact-based severity, clear roles, a mitigation-first plan, timed status updates, and real resolution criteria.
Before & after
Same prompt, same agent — the only difference is the skill.
That's stressful — let's work through it. Here's a general approach to incident response: 1. **Assess impact** — how many users are affected, and what's the business impact? 2. **Communicate** — let stakeholders know you're investigating 3. **Investigate** — check recent deploys, error rates, dependencies, and infrastructure 4. **Mitigate** — if a recent deploy is the cause, consider rolling back 5. **Resolve** — apply a fix and verify 6. **Post-mortem** — document what happened and how to prevent recurrence Rolling back a recent deploy is often the fastest path to recovery, even before you understand the root cause. What have you checked so far?
SEV1. Revenue-impacting, no workaround. Work top to bottom, don't skip.
RIGHT NOW — first 5 minutes
1. You are Incident Commander. Say so in channel. IC does not debug —
the moment you're in the code you've stopped commanding.
2. Open #inc-checkout-<date>. One channel, all traffic.
3. Assign: one Ops lead (investigates), one Comms (status page,
stakeholders). If you're alone, IC + Ops and post to status page
yourself every 15 min regardless.
4. Status page NOW, before you know anything:
"We're investigating an issue with checkout. Next update in 15 min."
MITIGATE BEFORE YOU DIAGNOSE
Last deploy inside the window? Roll back. Do not wait to confirm
causation — a rollback that turns out to be unrelated costs you five
minutes; a diagnosis-first approach costs you the outage.
No recent deploy? Check in order: dependency status pages, DB
connection saturation, expired certs, upstream payment provider.
TIMELINE — start it now, not after
Every action, timestamped, in channel as it happens. Reconstructing
this tomorrow from memory is where post-mortems go wrong. The channel
IS the timeline if you keep the discipline.
CADENCE
Status page every 15 min even with nothing new. Silence reads as
worse than the outage.
RESOLVED CRITERIA — decide before you're tempted
Error rate under baseline for 15 consecutive minutes AND a successful
synthetic checkout. Not "looks fine now."
AFTER
Post-mortem within 5 business days. Blameless, timeline-driven,
action items with owners and dates. If it has no owner it won't happen
and the next incident is the same one.
What's the last deploy time?About this skill
Prod is down and five people are debugging in five threads. Nobody has told customers anything, and someone just restarted the box that held the evidence. This skill acts as your incident commander. It makes the severity call, assigns roles, pushes mitigation before root cause, writes your status updates, and refuses to call it resolved until the metrics say so.
What it does
- Sets severity by user impact, not by which component broke. It uses a ready SEV1-3 matrix and the rule "when torn, go higher."
- Gives you an action list for the next 10 minutes. It asks "what changed?" first, then works a mitigation ladder from rollback to flag-off to failover to load shedding, with restart as the last resort.
- Catches dangerous moves before you make them, such as rolling back code over a forward-only migration, wiping hosts in what is actually a security incident, or calling "fixed" when the deploy finishes.
- Drafts internal and external status updates. Each one has a next-update time, uses no speculation, and describes impact in user terms.
- Tracks hypotheses with timeboxes and escalation triggers, so a stuck incident doesn't drift for hours.
- Rebuilds a timestamped timeline from pasted Slack or logs. It also handles shift handoffs and sets up severity levels and on-call rotations for new teams.
What you get
During an incident, you get a compact incident card: provisional severity, roles, owned next actions, a hypothesis board, ready-to-send status updates, and explicit resolution criteria. Outside an incident, you get the specific artifact you asked for, such as an update, a timeline, a severity matrix, or an on-call setup.
Best for
On-call engineers, engineering managers, and small startup teams who handle production outages without a dedicated SRE org, or who want their incidents to stop dragging on.
SKILL.md preview
---
name: live-outage-incident-command
description: Runs live production incident command for outages and degradations. It sets severity by user impact, separates roles, works a mitigation-first ladder starting from "what changed", sends timed status updates, and declares resolution only on recovered user-facing metrics, then hands off a clean timeline for review. Use when the user says "prod is down", "we have an outage, what do I do", "help me run this incident", "write a status update for customers", "our incidents keep dragging on for hours", "everyone is debugging and nobody is in charge", "set up severity levels and on-call for our team".
---
# Live Outage Incident Command
… (sign up to view the full skill)Featured in
More development skills
View all Development skills →Chaos Experiment and Game Day Planner
Plans chaos experiments and game days: hypothesis, blast radius, abort conditions, tool manifests, rollback, and post-run review.
Claude Code Cost and Latency Routing
Configure Claude Code Router with model tiers, explicit fallbacks, compatibility checks, and a cost-aware validation plan.
CI/CD Pipeline Builder with Gated Deploys
Generates CI/CD workflows from your repo's real stack: cached fast-fail checks, pinned actions, and staging-to-prod deploys with gates.
Terraform Modules and Safe Deployments
Get reusable Terraform modules, safe state migrations, explicit provider wiring, and CI gates tied to reviewed plans.