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
Flexible Targeting
Multiple Channels
Smart Retries
How Escalation Works
When an incident triggers an escalation policy:Viewing Escalation Policies
The Escalation Policies page shows all your policies: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
Open Create Dialog
Configure Policy Settings
- 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
Add Escalation Levels
- Click Add Level to create your first level
- Configure targets, channels, and timing
- Add more levels as needed
Save Policy
Configuring Escalation Levels
Each level defines who gets notified and how.Level Timing
- Level 1
- Level 2+
- Final Level
Notification Targets
Add targets using the dropdown selectors:Target Mode
Choose how targets are notified:Parallel
- Everyone receives notifications at once
- First person to acknowledge handles it
- Best for: Time-critical incidents
Sequential
- Moves to next target after max retries
- Stops when someone acknowledges
- Best for: Defined escalation order
Example: Sequential vs Parallel
Example: Sequential vs Parallel
- 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: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
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
- 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
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
Editing Policies
Find the Policy
Open Edit Dialog
Make Changes
Save Changes
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
Open Delete Dialog
Confirm Deletion
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
Best Practices
Start with On-Call
Start with On-Call
Increase Reach at Each Level
Increase Reach at Each Level
- Level 1: Individual on-call
- Level 2: Team or backup
- Level 3: Management
Set Appropriate Timeouts
Set Appropriate Timeouts
- Critical: 3-5 minute timeouts
- High: 5-10 minute timeouts
- Medium: 10-15 minute timeouts
Use Multiple Channels
Use Multiple Channels
Configure Retries Wisely
Configure Retries Wisely
Test Your Policies
Test Your Policies
Document Policy Purpose
Document Policy Purpose
Common Patterns
24/7 Critical Response
24/7 Critical Response
Business Hours Only
Business Hours Only
Follow-the-Sun
Follow-the-Sun
- EMEA Policy → EMEA on-call schedule
- APAC Policy → APAC on-call schedule
- Americas Policy → Americas on-call schedule
VIP Customer Escalation
VIP Customer Escalation
Escalation Status
Incidents track their escalation status: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

