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
- 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
- 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 Tertiary’ rotation 25 total minutes after the incident was created, 15 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 “database”:
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.
UI/UX in VictorOps
These new features and benefits that are brought about by the new Escalation Policies functionality also bring some slight UI/UX improvements to VictorOps as well. These changes are outlined in the screenshots below.
The Rotations tab now displays the specific Escalation Policy that is using that specific rotation:
The team view shows the on-call schedules for each policy in a calendar-style format
You can also see how the policies from all teams can be used globally. See how the red “pills” in the screen below indicate which team the policy came from:
The Incident Pane shows multiple ways to reroute incidents. Notice the list of escalation policies that are affiliated with your team:
You can take on-call for policies (i.e. primary or secondary), not for teams:
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.
An Escalation Policy is executed based on your routing rules. An Escalation Policy determines which incidents are routed, to whom they are routed, and how they are escalated. VictorOps gives you the flexibility to create an Escalation Policy that fits your organization’s existing processes.
As an example, when an incident is routed to the following Escalation Team, its escalation policy will:
- Immediately notify the on-call user in the Dev_Rotation. It will also send an email to this team’s email address.
- The system will wait 10 minutes, and if the incident has not been acknowledged, @ngrieb’s personal notification policy will be executed
- If the incident is still unacked after an additional 30 minutes, the Database team’s escalation policy will be executed.
- Finally, if the incident is still unacked after an additional 60 minutes (cumulative time of 10 + 30 + 60 = 1 hour 40 minutes after initial trigger), a webhook will be executed to reboot the server.
When an Escalation Policy is executed and a User is being notified, the User’s personal paging policy determines how they will be contacted.
Escalation Policies can also deliver incident notifications to email addresses or webhooks for integration with your external systems.