Skip to main content

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:
Incident Created

   Level 1 → Notify targets (call, SMS, email)

   No response within timeout?

   Level 2 → Notify next set of targets

   No response within timeout?

   Level 3 → Final escalation

   Still no response?

   Repeat cycle (if configured)
The escalation stops immediately when someone acknowledges the incident.

Viewing Escalation Policies

The Escalation Policies page shows all your policies:
ColumnDescription
PolicyName, description, and default indicator (⭐)
Escalation FlowPreview of levels with target counts
StatusActive or Inactive
ActionsEdit, 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
The default policy is indicated with a star icon (⭐).

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 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 TypeDescription
UsersIndividual team members
TeamsAll members of a team receive notifications
SchedulesThe current on-call person from the schedule
Combine target types for comprehensive coverage. For example, Level 1 might target the on-call schedule, while Level 2 adds the entire team.

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
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
Sequential Mode:
  • 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:
ChannelDescriptionBest For
CallPhone call with retry supportUrgent, must reach someone
SMSText messageQuick notifications
EmailEmail notificationDetailed information, audit trail
WebhookIntegration notificationsSlack, 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
Settings: 2 retries, 30-second delay
T=0:00  Call attempt #1 → No answer
T=0:30  Call attempt #2 (retry #1) → No answer
T=1:00  Call attempt #3 (retry #2) → No answer
T=1:00  Max retries reached
        → Sequential: Move to next target
        → Parallel: Mark target exhausted

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

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
Level 2: Engineering Team
  • 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
Level 3: Management
  • 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
Settings: repeatLimit=2, repeatDelay=30 min
Pass 1:
  Level 1 → Level 2 → Level 3 (no acknowledgment)

  [30 minute delay]

Pass 2:
  Level 1 → Level 2 → Level 3 (no acknowledgment)

ESCALATION EXHAUSTED
(No more repeats, incident marked as exhausted)

Reordering Levels

Levels can be reordered after creation:
  1. Open the policy for editing
  2. Use the Move Up (↑) and Move Down (↓) arrows
  3. Levels are renumbered automatically
  4. 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
Editing a policy affects all future escalations using it. Active escalations continue with their original configuration.

Duplicating Policies

Create a copy of an existing policy:
  1. Click the three-dot menu (⋮)
  2. Select Duplicate
  3. A copy opens in the create dialog with “(Copy)” appended to the name
  4. Modify as needed and save
Use duplication to create variants for different scenarios (e.g., business hours vs after-hours versions).

Deleting Policies

1

Open Delete Dialog

Click the three-dot menu and select Delete
2

Confirm Deletion

Review the warning and click Delete
Deleting a policy removes all its levels. Make sure no services or routing rules depend on it.

Escalation Flow Visualization

The policy list shows a preview of each policy’s escalation flow:
Level 1 (3 targets) → 5m → Level 2 (2 targets) → 10m → Level 3 (1 target)
This helps you quickly understand the escalation structure without opening each policy.

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

Level 1 should typically target an on-call schedule. This ensures the designated responder is contacted first before broader escalation.
Each level should reach more people or higher authority:
  • Level 1: Individual on-call
  • Level 2: Team or backup
  • Level 3: Management
Balance urgency with reasonable response time:
  • Critical: 3-5 minute timeouts
  • High: 5-10 minute timeouts
  • Medium: 10-15 minute timeouts
Don’t rely on a single channel. People might miss calls but see SMS, or vice versa.
2-3 call retries with 30-second delays gives responders time to answer or call back without excessive notification fatigue.
Create test incidents to verify escalation flows work as expected before relying on them for production.
Use the description field to explain when this policy applies and any special considerations.

Common Patterns

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
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.
Create separate policies for each region:
  • EMEA Policy → EMEA on-call schedule
  • APAC Policy → APAC on-call schedule
  • Americas Policy → Americas on-call schedule
Use routing rules based on time or incident origin.
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:
StatusDescription
TriggeredEscalation active, Level 1 in progress
EscalatedMoved to a higher level
AcknowledgedSomeone responded, escalation stopped
ExhaustedAll levels and repeats completed without acknowledgment

Troubleshooting

  1. Verify the policy is set to Active
  2. Check that a routing rule or default policy is configured
  3. Confirm the service has escalation enabled
  4. Look for initial delay settings that might postpone escalation
  1. Check target resolution (teams expand to current members)
  2. Verify schedule is showing correct on-call person
  3. Review target mode (parallel vs sequential)
  4. Check routing rules aren’t selecting a different policy
  1. Verify user contact methods are configured correctly
  2. Check notification channel is enabled for the level
  3. Confirm phone numbers are in correct format
  4. Review webhook configurations if using integrations
  1. Someone may have acknowledged without you knowing
  2. Check incident status in the incident timeline
  3. Verify level timeout settings are sufficient
  4. Review call retry settings
  1. Ensure acknowledgment was properly recorded
  2. Check for multiple simultaneous escalations
  3. Verify the incident ID matches
  4. Review incident timeline for acknowledgment event

Quick Reference

Target Modes

ModeBehavior
ParallelAll targets notified simultaneously
SequentialTargets notified one by one

Notification Channels

ChannelRetriesDelivery
CallYes (configurable)Synchronous
SMSNoFire-and-forget
EmailNoFire-and-forget
WebhookNoFire-and-forget

Default Settings

SettingDefault Value
Target ModeParallel
Call Retries2
Retry Delay30 seconds
Level Delay5 minutes
Repeat Limit1 (no repeat)
Repeat Delay30 minutes