An escalation policy controls what happens when a notification isn't acknowledged. Each policy is a list of levels, and each level says "after N minutes, do X." If nobody answers the call, sends the SMS reply, taps the push, or clicks the email link, the policy advances to the next level.
Plan availability: Escalation policies are available on the Starter plan and up. See Plans & Billing.
In JAMS Incident Management, a policy belongs to an on-call rotation. The Support Rotation has its own escalation behavior. The Database Rotation has its own. A flow that targets a rotation automatically inherits that rotation's policy — you don't have to remember to wire it on every flow.
Setup
Open On-Call Rotations, pick the rotation you want to configure, and click Add Escalation (or Edit Escalation if one already exists).
You'll see a modal that lets you build the escalation ladder one level at a time:
Level 1 Mode: Notify current on-call Escalate after: 10 minutes
Level 2 Mode: Re-notify the same person Escalate after: 10 minutes
Level 3 Mode: Next person in rotation Escalate after: 20 minutes
Level 4 Mode: Notify a different rotation → Manager Rotation
Each level has two things to configure: a mode (what kind of escalation step it is) and an escalate-after timer (how long to wait before moving on if nobody acknowledges).
Each level's timer is honored independently. A 10 / 10 / 20 ladder advances 10 minutes after Level 1, another 10 minutes after Level 2, then 20 minutes after Level 3 — each wait is measured from when the previous level fired, not from a single flow-wide clock.
The five modes
Notify current on-call
Pages whoever is currently on-call for the rotation. This is the typical Level 1 — the first ping.
Re-notify the same person
Pages the same person who was notified by the previous level. Use this when the failure mode is "did they see it?" — sometimes the first call goes to voicemail, the first SMS gets buried, and a second ping fixes it.
Next person in rotation
Advances to the next member in the rotation order and notifies them. Use this when the failure mode is "they're truly unavailable" — the on-call is in a meeting, on a plane, or asleep, and someone else needs to step in.
Notify a different rotation
Escalates out of the team entirely — e.g., to a Manager Rotation or a Director Rotation. Pick which rotation(s) to escalate to when you choose this mode.
Notify a specific person
Pages specific people directly, by name. They don't have to belong to any rotation. Use this for a fixed fallback — a manager or director who should be pulled in if nobody on the team answers. Pick the person (or people) when you choose this mode.
Example: the classic 3-level support pattern
Support Rotation
Members: Alice, Bob, Charlie (weekly handoff)
Escalation:
Level 1 Notify current on-call → 10 minutes
Level 2 Re-notify the same person → 10 minutes
Level 3 Next person in rotation → 20 minutes
Level 4 Notify a different rotation → Manager Rotation
A flow targeting the Support Rotation now behaves like this:
0:00 Alice gets paged (call + SMS + push)
0:10 Alice gets paged again — same ping, second chance
0:20 Bob gets paged (next in rotation)
0:40 Manager Rotation's current on-call gets paged
If Alice acknowledges at any point, the chain stops immediately. The same goes for Bob, the Manager, or anyone else in the policy.
Manual escalate from the alert
Sometimes the on-call person knows they can't handle this one — they're heads-down on something else, or it's outside their expertise. They don't have to wait for the timer to expire.
When there's a next responder to escalate to, every channel offers a manual escalate option:
- Voice call: "Press 1 to acknowledge, press 2 to repeat, press 3 to escalate"
- SMS: reply
1to acknowledge,3to escalate - Push notification: tap the Escalate action button
- Email: click the Escalate button next to Acknowledge
Hitting escalate jumps straight to the next level — no waiting.
Why this matters: the escalate option only appears when someone is queued after the current recipient. A single-recipient dispatch — the last level of a policy, or a flow that notifies just one person — has nowhere to escalate to, so no channel shows an escalate option for it. You'll still see Acknowledge and Repeat.
What happens after the last level
If the chain runs all the way through every level and still nobody has acknowledged, the policy doesn't give up. It waits the last level's own escalation window — measured from the most recent notification, so the final responder gets their full window — and then starts the whole ladder again from level 1.
There is no round cap. It keeps cycling until one of these ends it:
- Somebody acknowledges. One acknowledgement resolves every channel in the group.
- You deactivate the flow. Pausing the flow cancels the group instead of re-queuing it.
- The flow's cooldown throttles it. See Runaway control for the anti-loop limits that stop a misbehaving source from paging repeatedly.
So an alert nobody answers keeps asking. That is deliberate — an unacknowledged critical alert going quiet on its own is the failure this product exists to prevent — but it does mean a flow pointed at a source that fires constantly needs its cooldown set, not just its escalation policy.
Repeating the whole policy on purpose
A policy has a Repeat setting (1–10, default 1) on the Escalation Policies page. It controls how many times the entire ladder is queued up in one dispatch — the equivalent of PagerDuty's "num loops".
With Repeat set to 3, a two-level policy queues six steps at once: levels 1, 2, 1, 2, 1, 2. This is different from the looping above:
| Repeat | The loop after the last level | |
|---|---|---|
| Set by | You, per policy | Automatic |
| When | Planned up front, at dispatch | Only after every step has been sent |
| How many | Exactly what you chose | Until acknowledged or stopped |
Leave Repeat at 1 unless you specifically want a second pass to arrive faster than the post-ladder loop would deliver it.
No escalation policy: the default
A flow whose recipient has no escalation policy still escalates — it just uses one uniform timer instead of per-level timers. JAMS notifies the first recipient, waits the flow's own escalation interval (default 5 minutes), advances to the next recipient, and repeats. Every step uses the same interval. You set this interval when you build the flow; see Core Concepts for where it lives.
The per-level timers described above are a feature of escalation policies specifically. Without a policy, you get the single flow-wide interval.
Wiring it to a flow
You don't. That's the point. Build a flow, pick an On-Call Rotation as the recipient, and the rotation's policy drives delivery automatically. The flow doesn't need to know what the policy is.
If you change a rotation's policy later, every flow that targets that rotation picks up the change immediately — no flow edits needed.
Removing a policy
In the rotation's escalation modal, click Remove Policy. The rotation reverts to legacy round-robin behavior — notify the current on-call, wait the flow's own escalation interval, advance to the next person, repeat.
Advanced: multi-rotation policies
The standalone /escalation-policies page still exists and lets you build policies that aren't owned by any single rotation. This is useful in unusual cases — e.g., a policy where Level 1 targets two different rotations simultaneously. Most teams won't need this; rotation-owned policies cover the common patterns.