Skip to main content

​
What is an escalation policy?

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
When you create an escalation policy, a Default Escalation Path is automatically created with Audible notifications enabled. This default path cannot be deleted and acts as a fallback if no other escalation paths match.

​
Step 1: Who Do We Notify?

Some alerts resolve themselves quickly. If this is common, consider adding a short Wait period at the top of your Escalation Path set up before the first escalation step so transient issues don’t immediately page responders.
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

​
Paging Strategies

Each escalation level has a paging strategy that controls which pageable responders are notified and in what order when the level triggers. You can configure the strategy when adding targets to a level.
Paging strategies apply only to pageable targets — users, schedules, and team responders. Slack channel targets (added for visibility) and Escalate targets always fire regardless of the strategy selected.
​
recommended
Pages the person currently on-call for any schedule targets in the level. Individual user targets are always paged directly. This is the standard strategy and the right choice for most escalation levels.
​
Pages all members of every schedule in the level at once, regardless of who is currently on-call. Use this for critical escalation levels where broad coverage matters more than targeted paging.
​
Randomly selects one pageable responder from the level and pages only them. Useful when any responder in the group is equally qualified and you want to avoid alerting everyone at once.
​
Rotates the first-paged responder across incoming alerts — Alert A pages User 1, Alert B pages User 2, and so on. Distributes alert load evenly over time. Learn more in the Round Robin documentation.
​
Pages each pageable target in the level sequentially within a single alert, cycling through all members before escalating to the next step. Learn more in the Round Robin documentation.
When a Team is added as a notification target, you can choose to page all team members, team admins only, or escalate directly to the team’s own escalation policy.
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.
If your alert source sends a re-trigger event, Rootly will re-page the responder who last acknowledged the alert. If the alert remains unacknowledged, escalation continues according to the policy’s steps.

​
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. The path has a single time zone that applies to every time restriction on it — Rootly evaluates each window in that zone.
  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. Rootly recommends 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.
    2. Note: Selecting All day covers the selected day from 12:00 AM to 12:00 AM — the window ends at midnight, not at the start of your next working day. For example, a weekend deferral set to All day on Saturday and Sunday closes at 12:00 AM on Monday: deferred alerts trigger at midnight, and alerts arriving between midnight and the start of business on Monday are not deferred. To hold alerts until Monday morning, add a Monday time block from 12:00 AM to your working start time (for example, 12:00 AM – 9:00 AM).
  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. Rootly recommends 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 any time.

​
Frequently Asked Questions

No, only alerts from Alert Sources, Live Call Routing, and Rootly’s API are deferred. This means that any manual pages (in other words, alerts created by a user either directly in the web app or on Slack), alerts created through workflows, and any alerts from Heartbeats will not be deferred.Note: Rootly will only defer up to 50 Alerts at a time per escalation policy.
Deferred alerts can be grouped. However, Rootly only groups deferred alerts together: paging alerts will never be grouped with deferred alerts. This ensures that any urgent alerts that should page never get deferred until a later date.

​
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
Deleting an escalation policy is permanent. To disable a policy temporarily, unassign it from all teams and services instead.

​
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

Escalation continues through all steps and repeat cycles until the alert is acknowledged or the policy completes.
Yes. If an acknowledgment timeout is configured and expires without resolution, escalation may resume.
Yes. Using an Escalate target triggers the destination policy while the original policy continues in parallel.
Yes. A Slack channel isn’t tied to a single policy — add it as a notification target on a level in each escalation policy where you want it to post. The same channel can appear on as many policies, and as many levels within them, as you need.Slack channels are added for visibility, so the channel is notified whenever a level it’s attached to fires, regardless of that level’s paging strategy.
No. Escalation policies page responders. Incident creation is controlled separately through alert routing and workflows.
The step still runs and waits its full delay before escalating. Rootly does not auto-skip a step that has no one on call — if you build a step that points at a schedule with a coverage gap (for example, a business-hours schedule outside business hours), the alert sits there for the configured delay, pages no one, then moves to the next step.To get “skip the layer if nobody is on call” behavior, model it with Dynamic Paths instead of relying on the order of steps in a single path:
  • Build one Escalation Path with a working-hour rule (or a time restriction) that matches your business-hours coverage. Put the business-hours schedule as Step 1 and the 24/7 fallback schedule as Step 2.
  • Build a second Escalation Path for the inverse window (no working-hour match) that goes straight to the 24/7 fallback as Step 1.
Outside business hours, the first path doesn’t match, the second path fires immediately, and the 24/7 schedule pages without the empty-step delay.For the alternative case where you want to defer a low-urgency alert until coverage resumes (rather than page the fallback right away), use a Deferral Path instead.
There’s no in-product “Download” or “Export” button for escalation policies today — bulk export is programmatic. Two paths cover the common needs:
  • API. GET /v1/escalation_policies returns every policy on your account. Walk into each policy with GET /v1/escalation_policies/{id}/escalation_paths and GET /v1/escalation_paths/{id}/escalation_levels to capture the full structure including paths and per-step targets. JSON output is the most flexible source for backups, audits, or feeding into other tools.
  • Terraform. Use the Terraform provider with the rootly_escalation_policy, rootly_escalation_path, and rootly_escalation_level resources. The Importing Existing Resources workflow pulls existing policies into Terraform state so they live in source control going forward.
Timestamps in Slack alert notifications use the time zone configured on the escalation path that routed the alert — the same zone that decided the path matched in the first place. Because a path has one time zone that applies to every time restriction on it, there’s no ambiguity when a path has multiple restrictions.If the matched path has no time zone set (for example, the Default Escalation Path with no time restrictions), timestamps fall back to your organization-wide time zone.For example, an alert routed by a path configured for London time shows London time in its Slack notifications, even if your organization’s time zone is set to a different region.