The New Escalation Policy functionality enables you to associate each VictorOps team with multiple escalation policies, which provides flexibility to VictorOps by eliminating the restriction of one policy per team. This:
Removes redundancy by folding multiple escalation policies under a single team
Scales more efficiently by empowering each team to have multiple, diverse escalation policies to fit different scenarios
Increase support for DevOps by setting up policies that may include managers or other incident experts
Features and Benefits
Rename Teams: Before, teams did not have the ability to be renamed. Now, you can find a ‘Rename’ option in the options menu located to the very right of the team’s name on the Teams page within Settings.
- Multiple Escalation Policies: Before, single teams could only have one unique Escalation Policy. Now, single teams can have as many unique Escalation Policies as they want! Multiple Escalation Policies brings newly added benefits to VictorOps such as:
- Fewer Teams: Display who is on-call for each policy without creating two separate teams
- 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 either escalation policy
- Reuse Policies Across Teams: Reuse globally available escalation policies across multiple teams
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 Rotations tab shows the on-call schedules for each policy, and allows easy export:
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:
An escalation policy is executed based on your routing rules. An escalation policy determines who incidents are routed to and how they are escalated if not acknowledged.
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 person is being notified, their personal notification 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.