release-outage-response

name

release-outage-response

description

Orchestrates incident response when the spacecat-api-service Lambda is failing broadly after a deploy. Drives a diagnose-first workflow — confirm the outage, correlate it with the most recent release, and verify the suspect build locally — then gates a revert+push to prod main behind explicit human confirmation, and finally confirms recovery and files follow-up. Use when spacecat-api-service is returning widespread 500s shortly after a release; when a Lambda invocation error such as `TypeError: main2 is not a function`, `Cannot find module`, or a module-load `ENOENT` appears; when asked whether a release caused an outage; or when asked to revert / roll back a bad spacecat-api-service release. The manual step-by-step lives in docs/runbooks/release-caused-outage.md.

Release-Caused Outage Response

LLM-led companion to docs/runbooks/release-caused-outage.md. The runbook holds the exact commands and the worked example; this skill enforces the sequence, the diagnosis discipline, and the one hard safety gate.

Before starting, read docs/runbooks/release-caused-outage.md — work from its commands rather than reconstructing them. This skill tells you what to do and in what order; the runbook tells you how.

Operating rules

• Diagnose before reverting. Do not propose a revert until evidence supports it. Hold at least two hypotheses until one is confirmed (see Phase 2–3).
• One hard gate: never run the revert or the push to prod main without explicit human confirmation (Phase 4). This is the only irreversible, shared-state action in the flow — treat it as such.
• Verify locally first. A revert is cheap, but a wrong revert wastes the one cheap mitigation you have. Prove the suspect build is broken before you touch main (Phase 3).