Incident Response
Severity levels SEV1–SEV4
Bug priority and incident severity are separate scales. P-levels describe how urgently a known defect should be fixed. SEV-levels describe the real-time impact of a production event. A P2 bug might cause a SEV1 incident. An infrastructure outage can be SEV1 with no associated bug at all.
When we page
Only SEV1 and SEV2 trigger formal incident response.
That means paging, status page updates, leadership notifications, and mandatory RCCAs. SEV3 and SEV4 are handled through normal on-call triage and backlog work.
Why two scales
Priority (P-level) drives fix scheduling—how urgently engineers should patch a known defect. Severity (SEV-level) drives incident response—paging, communication, and leadership escalation during a live production event. They often correlate, but not always.
RCCA: Root Cause & Corrective Actions
For SEV1 and SEV2 incidents, a formal RCCA is required. This isn't about blame—it's a structured retrospective that documents root cause, contributing factors, and corrective actions so we learn from every serious incident. SEV3 incidents get RCCAs when the team determines there's enough to learn from.
Severity levels
Complete outage or data loss. All or most users affected. Revenue-impacting.
All-hands response. Status page updated. Leadership notified every 15 min.
Significant degradation. Major feature unavailable. Many users affected.
On-call + manager engaged. Status page updated. Stakeholders notified hourly.
Partial degradation. Workarounds available. Subset of users affected.
On-call investigates. Fix during business hours. Internal comms.
Minimal impact. Cosmetic or edge-case. Few users notice.
Tracked as a ticket. Fixed in a normal iteration cycle.