Overview
Escalation Policies define the notification sequence when an incident occurs. They ensure the right people are contacted in the right order until someone acknowledges and takes ownership. With multi-level escalations, flexible targeting, and automatic retries, you can build robust response workflows for any scenario.Multi-Level Escalation
Define sequential levels with increasing urgency and broader reach
Flexible Targeting
Target individuals, teams, or on-call schedules at each level
Multiple Channels
Reach responders via call, SMS, email, or webhooks
Smart Retries
Automatic call retries with configurable delays
How Escalation Works
When an incident triggers an escalation policy:Viewing Escalation Policies
The Escalation Policies page shows all your policies:| Column | Description |
|---|---|
| Policy | Name, description, and default indicator (⭐) |
| Escalation Flow | Preview of levels with target counts |
| Status | Active or Inactive |
| Actions | Edit, Duplicate, Delete |
Default Policy
One policy can be marked as the default. This policy is used when:- No routing rule matches the incident
- A service doesn’t have a specific policy assigned
Creating Escalation Policies
1
Open Create Dialog
Click the Add Policy button
2
Configure Policy Settings
In the Policy Settings tab:
- Name — Descriptive name (e.g., “Production Critical - 24/7”)
- Description — Explain when this policy should be used
- Set as Default — Toggle if this should be the fallback policy
3
Add Escalation Levels
In the Escalation Levels tab:
- Click Add Level to create your first level
- Configure targets, channels, and timing
- Add more levels as needed
4
Save Policy
Click Create to save your policy
Configuring Escalation Levels
Each level defines who gets notified and how.Level Timing
- Level 1
- Level 2+
- Final Level
Level 1 is triggered immediately when an incident is created.The delay setting determines how long to wait before escalating to Level 2 if no one acknowledges.Example: “Escalate to Level 2 after 5 minutes (if no response)”
Notification Targets
Add targets using the dropdown selectors:| Target Type | Description |
|---|---|
| Users | Individual team members |
| Teams | All members of a team receive notifications |
| Schedules | The current on-call person from the schedule |
Target Mode
Choose how targets are notified:Parallel
All targets notified simultaneously
- Everyone receives notifications at once
- First person to acknowledge handles it
- Best for: Time-critical incidents
Sequential
Targets notified one by one
- Moves to next target after max retries
- Stops when someone acknowledges
- Best for: Defined escalation order
Example: Sequential vs Parallel
Example: Sequential vs Parallel
Scenario: Level with targets Alice, Bob, CharlieParallel Mode:
- T=0:00 — Alice, Bob, Charlie all receive calls simultaneously
- T=0:01 — Bob answers and acknowledges
- Result: Escalation stops, Alice and Charlie calls become moot
- T=0:00 — Alice receives call (no answer)
- T=0:30 — Alice retry #1 (no answer)
- T=1:00 — Alice retry #2 (no answer, max retries reached)
- T=1:00 — Bob receives call (answers!)
- Result: Escalation stops, Charlie never contacted
Notification Channels
Select which channels to use for notifications:| Channel | Description | Best For |
|---|---|---|
| Call | Phone call with retry support | Urgent, must reach someone |
| SMS | Text message | Quick notifications |
| Email notification | Detailed information, audit trail | |
| Webhook | Integration notifications | Slack, Teams, custom systems |
Multiple channels can be enabled simultaneously. All selected channels fire in parallel for each target.
Call Retry Settings
When Call is enabled, configure retry behavior:-
Retry Count (0-5) — How many times to retry after initial call fails
- Total attempts = 1 + retry count
- Example: 2 retries = 3 total call attempts
-
Retry Delay (10-300 seconds) — Wait time between call attempts
- Default: 30 seconds
- Gives time for the person to call back
Example: Call Retry Flow
Example: Call Retry Flow
Settings: 2 retries, 30-second delay
Webhook Selection
When Webhook is enabled:- Select specific webhooks from your configured integrations
- If none selected: All tenant webhooks are triggered
- Webhooks receive full incident details and escalation context
Level Configuration Example
Example: 3-Level Production Policy
Example: 3-Level Production Policy
Level 1: On-Call Engineer
- Timing: Immediate (0 min delay)
- Targets: On-Call Schedule “Platform Engineering”
- Mode: Sequential
- Channels: Call, SMS
- Call Retries: 2 (3 total attempts)
- Retry Delay: 30 seconds
- Timeout: 5 minutes
- Timing: 5 minutes after Level 1
- Targets: Team “Backend Engineering”, Engineering Lead (user)
- Mode: Parallel
- Channels: Call, SMS, Email
- Call Retries: 2
- Timeout: 10 minutes
- Timing: 10 minutes after Level 2
- Targets: VP Engineering (user)
- Mode: Parallel
- Channels: Call, SMS, Email, Webhook (Slack)
- Call Retries: 2
- No further escalation
Repeat Settings
Configure what happens when all levels complete without acknowledgment:Repeat Limit
How many times to cycle through the entire policy:- 1 (default) — Single pass through all levels
- 2 — Policy repeats once (2 total passes)
- 3+ — Multiple repeat cycles
Repeat Delay
Wait time between policy repeats:- Default: 30 minutes
- Gives time for the situation to potentially resolve
- Or for responders to become available
Example: Repeat Cycle
Example: Repeat Cycle
Settings: repeatLimit=2, repeatDelay=30 min
Reordering Levels
Levels can be reordered after creation:- Open the policy for editing
- Use the Move Up (↑) and Move Down (↓) arrows
- Levels are renumbered automatically
- Save to apply changes
The first level always triggers immediately. Subsequent levels use their delay setting relative to when they’re reached.
Editing Policies
1
Find the Policy
Locate it in the list or use search
2
Open Edit Dialog
Click the three-dot menu (⋮) and select Edit
3
Make Changes
Modify settings, add/remove levels, adjust timing
4
Save Changes
Click Save to apply
Duplicating Policies
Create a copy of an existing policy:- Click the three-dot menu (⋮)
- Select Duplicate
- A copy opens in the create dialog with “(Copy)” appended to the name
- Modify as needed and save
Deleting Policies
1
Open Delete Dialog
Click the three-dot menu and select Delete
2
Confirm Deletion
Review the warning and click Delete
Escalation Flow Visualization
The policy list shows a preview of each policy’s escalation flow:Target Resolution
Targets are resolved at escalation time, not when the policy is created:User Targets
- Direct notification to the specified user
- Uses their configured contact methods
Team Targets
- Expands to all current team members
- If membership changes, new escalations use updated membership
Schedule Targets
- Resolves to whoever is currently on-call
- Handles overrides and rotation automatically
- If no one is on-call (coverage gap), target is skipped
Dynamic resolution means your escalation policies stay current with team and schedule changes.
Best Practices
Start with On-Call
Start with On-Call
Level 1 should typically target an on-call schedule. This ensures the designated responder is contacted first before broader escalation.
Increase Reach at Each Level
Increase Reach at Each Level
Each level should reach more people or higher authority:
- Level 1: Individual on-call
- Level 2: Team or backup
- Level 3: Management
Set Appropriate Timeouts
Set Appropriate Timeouts
Balance urgency with reasonable response time:
- Critical: 3-5 minute timeouts
- High: 5-10 minute timeouts
- Medium: 10-15 minute timeouts
Use Multiple Channels
Use Multiple Channels
Don’t rely on a single channel. People might miss calls but see SMS, or vice versa.
Configure Retries Wisely
Configure Retries Wisely
2-3 call retries with 30-second delays gives responders time to answer or call back without excessive notification fatigue.
Test Your Policies
Test Your Policies
Create test incidents to verify escalation flows work as expected before relying on them for production.
Document Policy Purpose
Document Policy Purpose
Use the description field to explain when this policy applies and any special considerations.
Common Patterns
24/7 Critical Response
24/7 Critical Response
Level 1: On-call schedule (sequential, call+SMS, 5 min)
Level 2: Entire team (parallel, call+SMS+email, 10 min)
Level 3: Management (parallel, all channels, 15 min)
Repeat: 2 cycles with 30 min delay
Business Hours Only
Business Hours Only
Level 1: Support team (parallel, email+SMS, 15 min)
Level 2: Team lead (sequential, call+SMS, 10 min)
Repeat: 1 cycle (no repeat)Combine with routing rules to use different policies after hours.
Follow-the-Sun
Follow-the-Sun
Create separate policies for each region:
- EMEA Policy → EMEA on-call schedule
- APAC Policy → APAC on-call schedule
- Americas Policy → Americas on-call schedule
VIP Customer Escalation
VIP Customer Escalation
Level 1: Dedicated support (sequential, call+SMS, 3 min)
Level 2: Account team (parallel, all channels, 5 min)
Level 3: Customer success + Management (parallel, 10 min)
Repeat: 3 cycles with 15 min delay
Escalation Status
Incidents track their escalation status:| Status | Description |
|---|---|
| Triggered | Escalation active, Level 1 in progress |
| Escalated | Moved to a higher level |
| Acknowledged | Someone responded, escalation stopped |
| Exhausted | All levels and repeats completed without acknowledgment |
Troubleshooting
Escalation not starting
Escalation not starting
- Verify the policy is set to Active
- Check that a routing rule or default policy is configured
- Confirm the service has escalation enabled
- Look for initial delay settings that might postpone escalation
Wrong people being notified
Wrong people being notified
- Check target resolution (teams expand to current members)
- Verify schedule is showing correct on-call person
- Review target mode (parallel vs sequential)
- Check routing rules aren’t selecting a different policy
Notifications not being received
Notifications not being received
- Verify user contact methods are configured correctly
- Check notification channel is enabled for the level
- Confirm phone numbers are in correct format
- Review webhook configurations if using integrations
Escalation stopping too early
Escalation stopping too early
- Someone may have acknowledged without you knowing
- Check incident status in the incident timeline
- Verify level timeout settings are sufficient
- Review call retry settings
Escalation continuing after acknowledgment
Escalation continuing after acknowledgment
- Ensure acknowledgment was properly recorded
- Check for multiple simultaneous escalations
- Verify the incident ID matches
- Review incident timeline for acknowledgment event
Quick Reference
Target Modes
| Mode | Behavior |
|---|---|
| Parallel | All targets notified simultaneously |
| Sequential | Targets notified one by one |
Notification Channels
| Channel | Retries | Delivery |
|---|---|---|
| Call | Yes (configurable) | Synchronous |
| SMS | No | Fire-and-forget |
| No | Fire-and-forget | |
| Webhook | No | Fire-and-forget |
Default Settings
| Setting | Default Value |
|---|---|
| Target Mode | Parallel |
| Call Retries | 2 |
| Retry Delay | 30 seconds |
| Level Delay | 5 minutes |
| Repeat Limit | 1 (no repeat) |
| Repeat Delay | 30 minutes |