Designing a SEV1-SEV4 severity matrix

WHAT THIS TESTS Whether you can make severity objective and tie it to response, rather than leaving it to whoever picks up the page. Interviewers want measurable criteria and a clear escalation mapping.

A GOOD ANSWER COVERS Anchor each level to impact dimensions you can measure: fraction of users or requests affected, revenue or transaction volume at risk, SLO or error-budget burn rate, data loss or corruption, and security or compliance exposure. SEV1 is broad outage, major revenue loss, data loss, or active security breach; SEV2 is significant degradation of a core flow for many users; SEV3 is limited or workaround-available impact; SEV4 is minor or cosmetic. Crucially, map each level to a response contract: time to acknowledge, who is paged and escalated, comms cadence, and whether leadership is engaged.

COMMON WRONG ANSWERS Purely subjective labels like bad versus very bad. Defining severity only by technical symptoms while ignoring business impact, or vice versa.

LIKELY FOLLOW-UPS How do you handle an incident that escalates from SEV3 to SEV1? Who has authority to set or change severity? How do you avoid severity inflation?

ONE CONCRETE EXAMPLE For a payments product, SEV1 means checkout is down for more than 10 percent of users or any confirmed data loss, paging the on-call plus engineering lead and notifying leadership within 15 minutes. SEV2 covers elevated latency degrading checkout for a region. SEV3 is a non-critical report failing with a workaround. SEV4 is a typo in an email template. Each row lists ack time, escalation path, and update frequency, so two engineers classifying the same event land on the same SEV and the same response.