Urgencies is a feature which allows you to customize how your team is notified based on the criticality of an incident: incidents can be either high-urgency (requires immediate attention) or low-urgency (it can wait). What does this mean for responders? As an incident responder, you can set up notification rules so that you won't be woken up for low-urgency incidents that can be handled in the morning, or you can set a service to notify you with only high-urgency or low-urgency notification methods at specific times of day.
Step 1: Configure Service
Urgencies are defined at the Service level, and all services will initially default to High. This can be adjusted within the settings of a service; to access the settings, navigate to the service you wish to adjust and click Edit Service.
You have the option to apply one of two (or four) options to all incidents originating from a particular service, depending on your account's plan:
High: Use high-urgency notification rules and escalate as needed
Low: Use low-urgency notification rules and do not escalate
High during service support hours, Low otherwise
Low during service support hours, High otherwise
Low-urgency incidents will not escalate. Only high-urgency incidents will escalate according to the rules defined in an escalation policy.
Additionally, for accounts with access to Support Hours, you can configure your settings to raise the urgency of all open incidents once on-call hours begin.
Step 2: Configure User Profile
Responders will next need to navigate to their User Profile and specify how they'd like to be notified based on the urgency of an incident.
It's a best practice to create several notification rules for high-urgency incidents and tier them so that the on-call responder will be notified numerous times until they acknowledge the incident.
With non-urgent incidents, however, the on-call responder may only want to receive a push notification, email, or no notification at all, for instance.
Use Case 1:
The level of urgency you choose for a service depends on your use case. For example, in this test we have two Nagios services. One is for CRITICAL Nagios events that require immediate attention, the other is for NON-CRITICAL Nagios incidents that don't require immediate attention.
We would want the on-call engineer to respond to incidents originating from the Nagios Critical service immediately. Incidents on this service will trigger as high-urgency.
On the other hand, there may be less critical incidents that need to be addressed, but that do not require our immediate attention. We'll configure the Nagios Non-Critical service to trigger low-urgency incidents.
Use Case 2:
Let's take a support team as another example. Since a support team responds to customer inquiries during business hours, we want incidents to be categorized as critical during business hours and non-critical after hours. This way they are fresh for work the next day!
However, once the team is back on-call the following morning, all open incidents should be raised to high-urgency. When an open incident is raised to high-urgency, PagerDuty will notify the assigned user according to their high-urgency notification rules.