An escalation policy is an ordered list of steps that OnCall works through when an incident goes unacknowledged. Each step has a delay (how long to wait before paging), a set of targets (users or teams to page), and a notify method (phone, push, or both). If nobody acknowledges by the time the last step fires, the escalation is marked exhausted and the incident remains open.
Team leads configure escalation policies. Policies are then attached to services and alert sources to determine who gets paged for which alerts.
Creating an Escalation Policy
- Go to Escalation Policies and click Create.
- Enter a name (e.g., "Critical — Tier 1 then Team") and optionally a description.
- Add the first step:
-
Delay — Set to
0for step 0 so it fires immediately when the incident triggers. - Targets — Add one or more users or teams. If you add a team, every member of the team is paged at that step.
- Notify methods — Choose phone, push, or both. Phone uses Voice to place an outbound call. Push delivers a mobile notification to registered devices.
-
Delay — Set to
- Click Add Step to add the next step.
- Set the delay for step 2 (for example, 15 minutes). This means if nobody acknowledges within 15 minutes of step 1 firing, step 2 fires.
- Continue adding steps as needed.
- Set Repeat times if you want the policy to cycle back to step 1 after the last step without acknowledgement.
- Click Save.
Step Timing
Delays are cumulative from the incident trigger time, not from the previous step. If step 1 has delay 0 and step 2 has delay 15, step 2 fires 15 minutes after the incident triggers — not 15 minutes after step 1.
The escalation engine runs every 2 minutes, so actual firing may be up to 2 minutes after the configured delay.
Targets: Users vs. Teams
- User — Pages a specific named user. Use this for the primary on-call person.
- Team — Pages every member of the team at once. Use this for a last-resort broadcast when individual targets haven't responded.
Teams are defined under Teams in OnCall. A team has a member list, and optionally a default escalation policy and schedule.
Default Policy
When a new organization provisions OnCall, a default escalation policy is seeded automatically. It has two steps: step 0 targets the primary on-call user (delay 0), and step 1 targets the entire team (delay 15 minutes). You can edit this policy or create additional ones.
Attaching a Policy to a Service or Alert Source
A policy does nothing until it's attached to something that creates incidents:
- Service — Set the default escalation policy when creating or editing a service. All incidents from that service use this policy unless overridden at the alert source level.
- Alert source — When creating an alert source, you pick an escalation policy. Alerts inbound on that webhook use this policy.
FAQ
What happens when all steps are exhausted with no acknowledgement?
OnCall marks the escalation as exhausted and publishes an internal event. The incident stays open in the triggered state. Someone will need to acknowledge it manually.
Can the same user appear in multiple steps? Yes. Some teams set up a policy where the primary on-call is step 0, then the same person plus a manager are step 1 (delay 10 min), then the whole team is step 2 (delay 30 min).
Does acknowledging an incident stop all remaining escalation steps?
Yes. The moment an incident moves to acknowledged, the escalation engine skips it. No further steps fire unless the incident is re-triggered or manually escalated.
Related
- ./alert-routing.md — How alerts are matched to policies
- ./schedules.md — Defining who is on call in a rotation
- ./escalating-manually.md — Manually moving to the next escalation step