Severities and Priorities

When organizations declare incidents, it's fundamentally important to categorize how severe the incident is. This allows teams to understand who needs to be engaged, what needs to be done, and the type of urgency and attention an issue demands.

Some organizations use "severities," while other organizations will make use of "priorities" to classify incidents. FireHydrant provides both.

Defaults

FireHydrant ships with several default Severities and Priorities. These allow organizations new to incident management as well as orgs testing things to get up and running quickly with best practices.

Severities

• SEV1 - SEV5: Standard industry indicators for the severity of an incident, with lower numbers (e.g. SEV1) indicating a higher severity than higher numbers (e.g. SEV5). Some organizations may start their numbering at SEV0.
• GAMEDAY: A FireHydrant-specific severity denoting a "test" incident. GAMEDAY incidents are excluded from metrics/analytics.
• MAINTENANCE: A FireHydrant-specific severity denoting a standard maintenance outage, or an "expected" outage. Learn more about creating Scheduled Maintenances.
• UNSET: A FireHydrant-specific severity denoting a lack of a severity or an unknown severity. Sometimes teams will declare UNSET incidents if they do not yet know how severe an issue is, and will escalate the severity as they work through the issue and discover facts.

If an incident is created without a Severity specified, FireHydrant will first check the Severity Matrix for any entries. If there are none, or no entries match the given conditions, FireHydrant defaults an incident to UNSET

Priorities

• P1 - P4: Standard industry indicators for priority levels of issues, including engineering tickets, incident tickets, and more. Like with Severity, the lower the number, the higher the urgency/impact.

If an incident is created without Priority specified, the default value is P4.

Customizing Severities and Priorities

Although FireHydrant provides defaults, organizations can customize and tailor both Severities and Priorities according to their needs.

An example of an additional configuration is a SEC0 severity to denote a security incident. This allows you to, for example, set different rules, such as creating a designated, private Runbook for Private Incidents.

Disabling Priority

Organizations who don't use the Priority field can disable it by heading to Settings > Organization > Incident Priority. If Priority is disabled, these are the locations where changes occur:

• Priority will no longer show up on incidents in Slack or on the user interface
• Priority cannot be selected during declaration or on forms in Incident Types, FireHydrant status pages, and Incident field settings
• Priority disappears as a filterable option from the Incidents list and Analytics pages. If any Saved Filters exist that use Priority, they will be marked as having "Invalid conditions"
• Priority disappears as a selectable condition in Runbooks and Runbook steps. If any existing steps use Priority as a condition, the condition will become invalid
• Priority disappears as a selectable condition in Jira Project Field Mapping. If any existing Jira project configurations use Priority in a field mapping or condition, they will become invalid
• Priority disappears as a selectable condition and usable field in Alert Routing. Any existing routes that use Priority will become invalid
• Priority disappears from any CSV data exports
• The Priorities page disappears from the Settings view

When disabling Priority, please ensure that each of the areas above in the product is not using Priority; otherwise, they may stop working correctly.

Next Steps

Now that you've gotten an overview of Severities and Priorities:

• See how you can use these severities and priorities to configure conditional execution on Runbooks.
• Configure automatic severities with the Severity Matrix.
• See a blog post about Severities and Priorities for more clarity and definition.