Have you ever experienced a time where someone in your company has marked an incident as a highly critical and when it is investigated it turns out to be a bug? The severity matrix will help by letting engineers define what severity levels different variants of customer impact and functionality condition will trigger. Let's take a look at how this is implemented.
As long as you are the owner of an organization on FireHydrant when you navigate to the severities tab you will see the Severity Matrix.
From here you can see two columns: Impact, which describes the customer impact and Condition which describes the current degradation state of the incident.
Impact has 4 options
1: All customers, self explanatory
2: Some Customers, this is intentionally left vague so that anyone can feel confident choosing this option if they don't know the radius of the incident yet
3: No Customers, maybe one of your pods died and nobody is affected yet but this is still something that requires remediation
4: Internal Customers, for all of your internal tooling that can break
Condition has 3 options
1: Unavailable, complete functionality loss
2: Degraded, something isn't working quite right but it's not fully unavailable
3: Bug, no critical logic is broken but it is still something that should be fixed
The fields on this matrix do not need to be completely filled out, leaving certain fields empty default to a 'Not Set' severity.
After you fill out the matrix, severity can be automatically set based off two questions. Who is impacted by this and how badly is it broken.
Now when anyone in your organization kicks off an incident you can be assured that it is being set to the appropriate severity based off your business needs.