Skip to content

Escalation policies

Escalation policies define what happens when an alert is not acknowledged within a specified timeout. They ensure that critical alerts always reach a responder, even if the primary on-call person is unavailable.

How escalation works

  1. An alert is routed to the current on-call responder.
  2. A countdown starts based on the configured timeout (in minutes).
  3. If the alert is not acknowledged before the timeout expires, it is routed to the next target in the policy.
  4. This process repeats until the alert is acknowledged or the policy chain is exhausted.

Creating an escalation policy

Navigate to On-call > Escalation Policies and click Create Policy.

Policy steps

Each policy consists of an ordered list of steps. A step defines:

FieldDescription
TargetA schedule, user, or team to notify
TimeoutMinutes to wait before escalating to the next step

Add as many steps as needed. For example:

Step 1: Backend Primary schedule → 5 min timeout
Step 2: Backend Secondary schedule → 10 min timeout
Step 3: Engineering Manager (user) → 15 min timeout

If no one acknowledges within 30 minutes, the alert reaches the engineering manager directly.

TIP

Keep the first timeout short (3-5 minutes) for high-severity incidents. Use longer timeouts for low-severity alerts to give the primary responder more time.

Incident type triggers

You can attach escalation policies to specific incident types so that different alert categories follow different escalation paths.

For example:

  • P1 - Critical: Escalate to the engineering manager after 5 minutes.
  • P2 - Warning: Escalate to the secondary schedule after 15 minutes.
  • P3 - Info: No escalation; alert expires after 60 minutes if unacknowledged.

Configure incident type triggers in the policy settings under Triggers.

INFO

If no incident type is specified, the policy applies to all alerts routed through it. You can create a default policy and override it with type-specific policies.

Policy chains

Policies can reference other policies as a step target. This lets you build nested escalation trees. For example, a team-level policy can escalate to an organization-level policy after exhausting its own steps.

Avoid deep nesting. Two or three levels of chaining is sufficient for most organizations.

Timeout behavior

The timeout countdown starts when the alert is delivered to the target, not when the alert is created. If delivery is delayed (e.g., due to a notification service outage), the countdown does not begin until the notification is sent.

Testing policies

Use the Test button on the policy detail page to send a simulated alert through the entire chain. This verifies that each step fires correctly without creating a real incident.

Built by the Batida team