1. Home
  2. Scheduling
  3. Configure Team Escalation Policy

Configure Team Escalation Policy

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

Execute Policy

  • 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)

Notify user

  • This will notify the user of your specification regardless of time of day

Execute webhook

Send an email to email address

  • This will send an email to the email address you specify

Time Delays

  • 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

Simultaneous Actions

  • 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

  • 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”:

set up routing key paging policies

Without Routing Key:

set up paging policies without a 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.

Escalation Policy 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 On-call Schedule tab 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:

reroute incidents with escalation pane

You can take on-call for policies (i.e. primary or secondary), not for teams:
take on-call for policies

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 September 16, 2019

Was this article helpful?

Related Articles