​

Overview

Escalation Policies define how Rootly notifies responders when an alert requires attention and what happens if that alert is not acknowledged in time. They are the backbone of on-call reliability—ensuring alerts reach a human, escalate predictably, and never fall through the cracks. An escalation policy answers three core questions:

• Who should be notified first?
• What should happen if no one responds?
• How long should Rootly keep escalating before stopping?

Escalation Policies can be assigned to a Team or Service. When that Team or Service is paged, their assigned escalation policy will trigger.

---

​

Create an Escalation Policy

Escalation policies are created from the On-Call section of the web app. To create a new escalation policy:

1. Navigate to On-Call → Escalation Policies
2. Click + Add Escalation Policy
3. Enter an Escalation Policy Name (required) and an optional description

---

​

Step 1: Who Do We Notify?

This step defines who is initially responsible for responding when an alert is triggered. Rootly supports notifying:

• Individual users
• On-call schedules
• Team members or team admins
• Slack channels (for visibility)
• Escalating to other Teams or Services

When multiple responders are eligible, you may optionally enable Round Robin assignment. This prevents the same person from being repeatedly paged and helps distribute alert load fairly. Rootly offers two Round Robin strategies:

• Alert-Based, which rotates ownership per alert
• Cycle-Based, which rotates ownership on a fixed cycle

Learn more in the Round Robin documentation. If an alert needs to be handed off to another group (such as a Team or Service), you can use an Escalate target. This triggers the target’s escalation policy in parallel, while the original policy continues executing.

---

​

Step 2: Add Escalation Steps

Escalation steps define what happens next if an alert is not acknowledged. Each step includes:

• A delay (in minutes)
• One or more notification targets

Delays start counting from the previous step (or alert creation for the first step). This allows escalation to widen gradually as urgency increases.

---

​

Step 3: Configure Repeat Behavior

If an alert remains unacknowledged after all steps complete, you can choose to repeat the escalation policy. When enabled, Rootly restarts escalation from the beginning and continues until:

• The alert is acknowledged, or
• The repeat limit is reached

This is commonly used for high-severity alerts where acknowledgement is mandatory.

---

​

Step 4: Save and Assign the Policy

Saving the policy does not activate it. Escalation policies only run once they are assigned to a Service or Team: when the Service or Team are paged, their assigned escalation policy will trigger.

1. Assign the escalation policy to a Team using the Owning team field.
   1. Note: Any admin of an Owning Team of an Escalation Policy will also inherit edit permissions for that Escalation Policy.
   
2. Assign the escalation policy to a Service from the Service Configuration section of the dashboard.
   

---

​

Dynamic paths

Escalation policies can contain multiple paths, each with its own rules and steps, allowing you to set up unique paging logic for different scenarios. Dynamic Paths allow you to model scenarios such as:

• Business hours vs after hours
• High vs low urgency alerts
• Deferring pages on weekends vs. weekdays

Rootly supports two kinds of dynamic paths: Escalation Paths, and Deferral Paths. Escalation Paths trigger the alert right away and begin paging based on the path’s logic. Deferral Paths will hold off on triggering the alert for a window of time, then trigger the alert and begin paging based on a related Escalation Path. Rootly evaluates Deferral Paths first, and can only be active during a certain time window. Once the time window lapses, Rootly will then evaluate Escalation Paths. All paths are evaluated top to bottom: the first path that matches the alert will be executed. Create a new Dynamic Path by navigating to the Paths tab, and select New Path.

​

Escalation Paths

Build Dynamic Escalation Paths when you want to have different paging logic for different types of alerts: for example, you may want to page different schedules depending on the time of day, or different users depending on the alert’s urgency. Set up your Escalation Path by:

1. Give your path a detailed Name. Make sure to use a descriptive name: when the path is executed for an alert, the path name will show on the alert’s timeline.
2. Add conditions for when the path should be executed. You can build conditions around alert details:
   1. Alert Urgency
   2. Alert Fields
   3. Services on the Alert
   4. Alert’s Payload (represented as a JSONPath).
3. Add any time restrictions: time restrictions limit the times of day for when the path can execute.
4. Select if the path will be executed if Any or All of the conditions are true: note that this logic applies to both the Conditions and Time Restrictions.
5. Set the notification type for the Path. See Audible vs. Quiet Notifications below to learn more about notification types.
6. Click Done, and begin adding the paging logic following the same process as your Default Path.

As you continue adding additional Escalation Paths, use the left-hand sidebar to drag-and-drop the paths into the order you’d like them to be evaluated in.

​

Audible vs Quiet Notifications

Each Escalation Path is either Audible or Quiet:

• Audible paths are designed to wake responders and trigger critical notifications
• Quiet paths respect Do Not Disturb and are used for lower-urgency alerts

Audible and Quiet paths map directly to each user’s notification rules. Learn more in Audible and Quiet Notifications.

​

Limits and Constraints

Escalation Paths have a few important limits:

• Maximum escalation levels: 20 per path
• Maximum targets per level: 25
• Repeat count: 1–9 cycles
• Maximum delay per step: 10,080 minutes (1 week)

Keeping policies simple and within these bounds improves reliability and maintainability.

​

Deferral Paths

Build Deferral Paths when you want to hold off on paging until a later time. We recommend using Deferral Paths for low-urgency alerts only, so your responders never miss an urgent page. When a Deferral Path is executed, it will hold off on triggering the Alert until the time window closes: once it closes, Rootly will trigger the alert and begin paging based on a matching Escalation Path. Set up your Deferral Path by:

1. Give your path a detailed Name. Make sure to use a descriptive name: when the path is executed for an alert, the path name will show on the alert’s timeline.
2. Add conditions for the types of Alerts that the path can map to. You can build conditions around alert details:
   1. Alert Urgency
   2. Alert Fields
   3. Services on the Alert
   4. Alert’s Payload (represented as a JSONPath).
3. Add a time interval: this is the window of time the path can match to an alert. Once the interval concludes, Rootly will trigger the alert.
   1. Note: All Deferral Paths must have a time interval.
4. Define the ‘After Deferral’ logic. Once the time interval lapses, this determines which Escalation Path gets triggered:
   1. Re-evaluate the alert: Rootly will review all Escalation Paths (in the priority order) and execute the first matching path.
   2. Choose path: Rootly will execute the defined path.
      1. We recommend choosing a specific path if you do not want to follow your standard paging logic like the alert came in during regular hours. For example, you may want to defer low-urgency alerts on weekends, and then come Monday start paging on the alert as if it was high-urgency.
5. Click Done. You can edit the path’s details at anytime.

---

​

Edit or Delete an Escalation Policy

To edit or delete a policy:

1. Navigate to On-Call → Escalation Policies
2. Click the … menu next to the policy
3. Select Edit or Delete

---

​

Best Practices

• Use short delays for high-severity alerts
• Assign policies to services whenever ownership is clear
• Avoid overly complex escalation trees
• Test policies with non-critical alerts before production use
• Use escalation paths to model time-based or urgency-based behavior

---

​

FAQs