Escalation Policies

​

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 continue escalating before stopping?

Once created, escalation policies are assigned to Services or Teams, where they become active and drive paging behavior.

---

​

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
• Teams or team admins
• Slack channels (for visibility)
• Other escalation policies (via escalation targets)

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, you can use an Escalate target. This triggers the destination team’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, which determines which alerts will trigger the policy.

---

​

Step 5: Assign the Escalation Policy to a Service or Team

Escalation policies only run once they are assigned to a Service or Team.
This assignment determines which alerts will trigger the policy.

​

Assigning to a Team

Assigning an escalation policy to a team ensures alerts routed to that team follow the defined escalation logic.

• Open the Team you want to configure
• Navigate to the On-Call tab
• Select the desired escalation policy

​

Assigning to a Service

Assigning an escalation policy to a service is recommended when alerts clearly map to a specific system or component.

• Open the Service you want to configure
• Navigate to the On-Call tab
• Select the desired escalation policy

---

​

Escalation Paths (Advanced)

Escalation policies can contain multiple escalation paths, each with its own rules, steps, and notification behavior. Paths allow you to model scenarios such as:

• Business hours vs after hours
• High vs low urgency alerts
• Different behavior based on alert metadata

Rootly evaluates paths top to bottom and selects the first matching path.
The Default Escalation Path is always positioned at the bottom and is used as a fallback when no other paths match. Each path can define:

• Matching rules and time restrictions
• An initial delay before escalation begins
• Its own escalation steps and repeat behavior
• Whether notifications are Audible or Quiet

​

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 policies 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.

---

​

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