Write an incident response plan for my app. Not a compliance document; a short playbook I'll actually use when things break. Write it in these sections: 1. What counts as an incident: define levels (SEV1 = users can't sign in or pay, SEV2 = partial degradation, SEV3 = minor issue that can wait for business hours). Include criteria so I don't waste time debating severity mid-outage. 2. Declare: how do I open an incident? Where does it get tracked (a channel, a doc, an issue)? Who gets pinged for each severity? Include a copy-pasteable declaration template with fields for what's happening, who's on it, and what's known so far. 3. Communicate: for SEV1/SEV2, post to the status page immediately with 'investigating' and update at least every 30 minutes even if the update is 'still investigating'. Silence is worse than uncertainty. Notify affected users by email if the outage exceeds a threshold I define here. 4. Investigate and mitigate: mitigation over root cause. Get service back first (rollback, feature flag off, restart, scale up) and dig into root cause after users are unblocked. Include the rollback runbook link and a pointer to structured logs and the error tracker. 5. Resolve: update status page to resolved, notify subscribers, and send an incident-close email if I sent one at the start. 6. Post-incident review: within a week, write up a short blameless retro. What happened, timeline, why the fix worked, what would prevent it, and one to three concrete follow-up items with owners and dates. Don't skip this; it's what turns incidents into learning instead of just trauma. Don't make this a fifteen-page policy. Keep it to one or two pages of things I'll actually do. The deliverable is the plan checked into the repo, the declaration template ready to copy-paste, and one live tabletop exercise where I walk through a hypothetical SEV1 to verify the plan works when I'm not thinking clearly.