1. Home
  2. Scheduling
  3. Team Escalation Policy

Team Escalation Policy

New Functionality

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 new functionality will allow you to:

  • Remove redundancy by folding multiple escalation policies under a single team

  • Scale 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, a ‘Rename’ option can be found in the options menu located to the 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:

Nobody On-Call?

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:

  1. Immediately notify the on-call user in the Dev_Rotation. It will also send an email to this team’s email address.
  2. The system will wait 10 minutes, and if the incident has not been acknowledged, @ngrieb’s personal notification policy will be executed
  3. If the incident is still unacked after an additional 30 minutes, the Database team’s escalation policy will be executed.
  4. 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.

Updated on February 7, 2018

Was this article helpful?

Related Articles