---
key: add-escalation-steps-to-a-rule
title: Add escalation steps to a rule
audience: staff
section: critical-alerts
routes: ["/critical-alerts/rules"]
permissions: ["critical_alerts.rules.manage"]
features: ["critical_alerts.core"]
since: 0.0.1
updated: 0.0.1
status: published
summary: Make an alert reach a second and third person when nobody acknowledges it, or when the first phone call fails.
keywords: [escalate, backup contact, nobody answered, second call, chain of contacts, on-call escalation, no answer, call the manager]
related: [create-a-critical-alert-rule, add-a-critical-alert-destination, publish-a-critical-alert-draft, run-escalations-and-monitors-now]
---

In the sidebar, open **Critical Alerts**, then **Setup**, then **Rules**. The page address is `/critical-alerts/rules`. Press **Edit** on the rule, then scroll to **Escalation**.

An escalation step is a follow-up delivery that runs while the incident is still active: call the manager 10 minutes after the technician, then the owner 10 minutes after that.

## Before you start

- Your admin has to give your role permission to manage critical alert rules.
- Create a destination for each person or group in the chain. See [[add-a-critical-alert-destination]].

## Steps

1. Press **Edit** on the rule. The **Edit rule** drawer opens.
2. Under **Escalation**, choose the **Timing anchor**. **Incident created time** counts every delay from when the incident opened; **Previous notification sent time** counts from the last message sent.
3. Turn on **Escalate on delivery failure** if the next step should run right away when a phone call is busy, unanswered or fails.
4. Press **Add escalation step**. A **Step 1** block appears.
5. Set **Delay minutes** (how long after the first delivery this step becomes due) and choose its **Destination keys**. Add a **Webhook URL** if another system should be told as well.
6. Set **Repeat count** and **Repeat interval minutes** if this step should try more than once.
7. Turn on **Bypass quiet hours** for steps that must deliver even during a destination's quiet hours; **Continue after acknowledgment** only if the chain should keep going after someone has claimed the incident; and **Trigger on previous failure** so this step runs when the previous call fails.
8. Press **Add escalation step** again for each further person. Use **Move up**, **Move down** and **Remove** to arrange them.
9. Save the rule with the button at the bottom of the drawer, then press **Publish** on the rule's row.

## What you see

- Each step reads "Runs after the initial destinations when the incident is still active."
- With no steps, the block reads "No escalation steps. The rule will notify only the initial destination keys unless you add a follow-up step."
- The rule's row now shows the number of escalation steps after its destination keys.

## If something looks different

- Steps never fire: the incident was acknowledged before the delay ran out, and **Continue after acknowledgment** is off. That is the usual and intended behaviour.
- A step fires sooner than expected: **Timing anchor** is **Previous notification sent time**, and a repeat notification reset the clock.
- Escalation runs on a timer. To push due steps through right now, see [[run-escalations-and-monitors-now]].

[[route:/critical-alerts/rules|Open Rules]]