Incident Response
Stop the bleeding, then make the same failure unwritable rather than merely known.
Overview
Incident response covers the order of operations while something is broken, what a small team can realistically commit to, and the part that actually pays: converting an incident into a structural change rather than a resolution note. It is written for a team without an on-call rotation, because that is the harder constraint and the one most guidance assumes away.
Why This Exists
Two things make incidents worse than they need to be, and neither is technical. The first is investigating before restoring. Understanding a failure is satisfying and restoring service is not, so the order inverts under stress unless it was decided in advance. The second is closing an incident once the symptom stops. A fixed symptom and a fixed cause feel identical at the moment service returns, and the difference only surfaces the next time. The output of an incident is not a resolution, it is a guardrail.
Restore first, understand second
Severity is about users, not components
What a small team can actually commit to
The postmortem is a guardrail, not a narrative
The failures worth expecting
Related Principles· 3
Related Documents· 4
Related Templates
Related Case Studies
Referenced By· 8
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Fixes the restore-before-investigate ordering, classifies severity by user impact, states honestly what a team without a rotation can commit to, and treats the postmortem as a guardrail with the possible outputs ranked. Closes with the recurring failure shapes.