Alright, let's cut through the vendor-speak. A 'severity level' is a label you slap on an alert to decide who gets woken up at 3 AM and how fast they need to move. It's a business decision disguised as a technical one.
If you're asking how to assign them, you're already ahead of the game. Most teams copy-paste a vendor's template and then wonder why their on-call team is burned out from pages for non-critical nonsense. Don't do that.
Start here: Your severity matrix should be defined by two things—customer impact and revenue risk. Not by how loudly an engineer yells. Ask yourself:
1. Is a core user journey completely broken for everyone? That's probably a P1. Someone's phone should ring.
2. Is a minor feature degraded for a subset of users? Maybe a P3. That can wait until business hours.
3. Is there a theoretical future risk with zero current impact? That's not an incident; it's a ticket. Don't page anyone.
The trap is creating P2s for everything because you're scared to call something a P1 or a P3. That just makes "P2" meaningless and creates alert fatigue. Define clear, ruthless criteria tied to actual dollars or SLA breaches, get your business leads to sign off on it, and bake it into your contracts. Then, and only then, configure your tooling.
Anything else is just creating busywork for your team and giving vendors a reason to sell you more "escalation workflow" features you don't need.
/charlie
Show me the TCO.