2 min lesson
Triage severity by impact and breadth
Pick two rows from the table in "Triage severity by impact and breadth" and explain the choice each one supports.
Step 1 of 2
Triage severity by impact and breadthblocking vs cosmetic, one user vs a fleet
- Affected scope
- Whole org / fleet
- Blocking
- Sev 1 - escalate now
- Degraded
- Sev 2
- Cosmetic
- Sev 3
- Affected scope
- Several users
- Blocking
- Sev 2
- Degraded
- Sev 3
- Cosmetic
- Sev 4
- Affected scope
- One user
- Blocking
- Sev 3
- Degraded
- Sev 4
- Cosmetic
- Sev 4
| Affected scope | Blocking | Degraded | Cosmetic |
|---|---|---|---|
| Whole org / fleet | Sev 1 - escalate now | Sev 2 | Sev 3 |
| Several users | Sev 2 | Sev 3 | Sev 4 |
| One user | Sev 3 | Sev 4 | Sev 4 |
A blocking issue across a fleet jumps the queue; a cosmetic glitch for one user can wait. Say the severity out loud and why.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Impact rising, breadth widening - the top-right corner escalates now; the bottom-left can wait.
Learn more
Full explanation
Don't escalate before you've isolated
Don't escalate before you've isolatedthe line interviewers probe
"It's broken, please look" is not an escalation - it's handing your unfinished work to a busier team. Escalate when you have a reproducible bug with a root cause that lives beyond configuration and not a step sooner. The exception is breadth: a fleet-wide outage you can't immediately isolate still escalates on impact, with the honest note that root cause is still open.
Learn more
Full explanation
Close the loop
Close the loopthe step that compounds
- 1Confirm the fix with the user, in their environment, not just in yours.
- 2Update the KB so the next instance is self-serve instead of a fresh investigation.
- 3Feed the signal back. If it's a recurring pattern, that's roadmap input Product wants - surface it, don't just close the ticket.
When asked "would you escalate this?", never answer with a flat yes or no. Answer with the bar: "I'd escalate once I have a reliable repro and a root cause beyond config - here's the repro and severity I'd attach." That shows you protect Engineering's time, which is exactly what a flat, talent-dense org is screening for.
Duplicate, vague escalations are how support loses Engineering's trust. Before you file, search for an existing report and dedupe. A sharp, deduplicated, well-scoped report is worth ten "hey can you look at this" pings.