• Meaning of "severity" in software incident context: Merriam-Webster defines it as the quality of being severe. Colloquially, it measures the effort and expense for service providers to manage and resolve events, indicates the seriousness of an issue based on user impact, and is designed to be simple for understanding urgency. In ITIL, major incidents cause serious business interruptions.
• Different meanings and purposes of "severity": It has many meanings and purposes when categorizing incidents, and can vary even within the same organization. Examples include categorizing customer impact, as an urgency or escalation signal, for post-incident task prioritization, as a contractual customer obligation, a trigger for post-incident analysis, a "quality" accounting index, and a qualitative measure of difficulty.
• Practices and challenges: Assigning severity levels during incidents is not straightforward, with uncertainty often present at the beginning. Severity levels can be used to communicate with non-engineering staff and kick off internal actions. There can be differences between post-incident labeling and during-incident assessment. Severity levels are not objective measures but negotiable constructs.
• What to do with the information: Explore how severity levels are used in your organization after an incident. Gather and analyze incidents with the same severity level, look for contrasting views on severity levels, and consider the impact on senior leadership scrutiny and incident metrics. Understanding these aspects is crucial for learning from incidents.