What is incident severity classification, and how do severity levels determine the response process, including who gets notified and how quickly the issue must be resolved?

Question

Accepted Answer

Incident severity classification is a system for categorizing incidents based on their impact on business operations and the urgency with which they need to be resolved. It ensures that the most critical issues receive immediate attention and the appropriate level of resources, while lower-impact issues are handled through standard processes without unnecessarily escalating the entire organization.

Most data centers use a four-level severity system, often labeled as P1 through P4, where P stands for priority, or Sev1 through Sev4, where Sev stands for severity. The classification is typically based on two factors: the impact of the incident, meaning how many users or systems are affected and how severely, and the urgency, meaning how quickly the issue needs to be resolved to prevent further damage.

A P1 or Sev1 incident represents a critical situation where a major service is completely down or severely degraded, affecting a large number of users or a business-critical application. Examples include a complete power failure in a data center zone, a core network outage affecting multiple customers, or a storage array failure causing data unavailability. P1 incidents trigger an immediate all-hands response. The on-call team is notified immediately, a war room or incident bridge is established, senior management is informed, and the team works continuously until the service is restored. The target resolution time for P1 incidents is typically measured in minutes to a few hours.

A P2 or Sev2 incident involves significant degradation of a service that affects multiple users but does not constitute a complete outage. Examples include a redundant component failure that eliminates the safety margin without causing an outage, performance degradation on a production system, or a partial cooling failure that requires load shedding. P2 incidents require prompt attention and dedicated resources, with a target resolution time of a few hours to one business day. The on-call team is engaged, but a full war room may not be necessary.

A P3 or Sev3 incident has a limited impact, affecting a small number of users or a non-critical system. Examples include a failed disk in a RAID array that is operating in degraded mode, a monitoring sensor failure, or a non-production server outage. P3 incidents are handled during normal business hours with standard resources. The target resolution time is typically one to three business days.

A P4 or Sev4 incident is a low-impact issue that does not affect current operations, such as a cosmetic defect in a management interface, a documentation error, or a request for a minor configuration change. P4 issues are addressed as time permits and are often handled as part of scheduled maintenance.

The severity level drives several aspects of the response. It determines the notification list, ensuring that the right people are alerted at the right level of urgency. It sets the expected response and resolution times, which are often codified in service level agreements. It defines the communication cadence, with P1 incidents requiring status updates every 15 to 30 minutes and lower severities requiring less frequent updates. And it determines the post-incident process, with P1 and P2 incidents typically requiring a formal post-incident review, while lower severities may only need standard ticket closure documentation.

As a technician, you must be able to accurately classify incidents based on objective criteria rather than emotional reaction. A server crash might feel urgent, but if it is a development server with no users, it is a P3, not a P1. Accurate classification ensures that critical issues get the resources they need without desensitizing the team through false alarms.