Team escalation policies set who is actually on-call for a given team and are the link to utilize any rotations that you have created
- Only Team and Global Admins are able to make changes to Escalation Policies
- Only users specified in the first step of an Escalation Policy will receive Timeline and Push notifications they are on-call, and will log hours in the on-call report as being on-call. If you would like users in subsequent steps of an escalation policy to receive these notifications and log these hours, follow this guide
Available Escalation Actions
A number of actions are available within each escalation policy. The different options are walked through below
Access the different escalation options by clicking on the “Select an escalation” dropdown menu. Scroll down to see all available options
- This action provides the ability to invoke a different escalation policy
Notify the on-duty users in rotation
- Our most common type of escalation action, this notifies the currently on-duty user(s) in the rotation you specify
Notify the next user in current on-duty shift
- This will notify the user(s) scheduled to be next up within the current on-duty shift
Notify the previous user within the current on-duty shift
- This will notify the user(s) that were on-duty previously within the current on-duty shift (or are currently in the schedule position to be the previous user)
- This will notify the user of your specification regardless of time of day
Notify every member of this team
- This will notify every member of the team that the escalation policy is created for. All users on the team will be paged for an incident, but only one user is required to ack the incident.
- This will execute the Escalation Webhook of your choosing
Send an email to email address
- This will send an email to the email address you specify
- The time delay you select for Step 1 will be in reference to either the incident’s beginning (most common) or from when the escalation policy is specified via another escalation policy
- You can tell which will be the case based on if a Routing Key is tied to the escalation policy
- All subsequent steps (Step 2, Step 3…) will have the time delay reference the previous step, not the incident’s beginning
- In the below example, Step 3 will notify the on-duty users on the “24×7 Backup” rotation 40 total minutes after the incident was created, 30 minutes after Step 2 was invoked
- The blue plus box allows for multiple actions to be performed simultaneously within one escalation policy step
Ignore Custom Paging Policies
- Checking this box will page the on-call user via their Primary Paging Policy and ignore any custom paging policies they have set. We recommend checking this box if this escalation policy handles high severity incidents.
- Routing keys are a key link to connect incidents to one of your established Escalation Policies. Please reference the Routing Keys article for more information.
- You can tell if an Escalation Policy is utilizing any routing keys or if it will need to be invoked via a manual reroute or another escalation policy based on the messaging below the Escalation Policy name
With Routing Key of “Default” and “lost”:
Without Routing Key:
Features and Benefits of using Multiple Escalation Policies
- Flexible SLA Configurability: Create urgent escalation policies that notify many people quickly for high-priority issues and relaxed escalation policies that merely send emails to distribution groups
- Waiting Rooms: Send incidents that often auto-resolve to Waiting Rooms to give them a chance to do so before alerting anyone
- Schedule Views: Surface the on-call schedules for each escalation policy via separate calendar links
- Internal Team Rerouting: Reroute easily within your team by setting up primary and secondary escalation policies
Flexible Take On-Call: Take on-call for the primary or the secondary escalation policy
- Flexible Manual Incident Creation: Send a manual incident to separate escalation policies
- Reuse Policies Across Teams: Reuse globally available escalation policies across multiple teams
For more detailed examples on how to benefit from the use of multiple escalation policies, please see our Tips and Tricks for Multiple Escalation Policies article.
There are some instances where a step within an Escalation Policy will reference paging an on-call user at a time when there’s no one on-call. In these and similar situations the resulting behavior is that no page will occur in this step. However, for the sake of consistency, the time delay before the next step will remain as configured.
For example, if an incident triggers an Escalation Policy during off-hours and there is no one on call to immediately page, the escalation policy will page no one and then wait however long is specified before executing step two.
When an Escalation Policy is executed and a User is being notified, the User’s personal paging policy determines how they will be contacted.