> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/on-call-management-and-escalations/escalation-policies.md). # Escalation policies Define escalation policies in ilert to guarantee that alerts are delivered through various channels until acknowledged or resolved. Escalation policies define whom to assign an alert to when an alert is triggered by an alert source. They consist of rules that specify a target (a user, a team, or a schedule) and an escalation timeout. By defining multiple escalation rules, you can ensure that an alert doesn't get missed if the first responder fails to acknowledge the alert. To create an escalation policy, navigate to **Escalation policies** and click on **Create new escalation policy**. Give it a name and optionally assign the policy to a team. ## Escalation rules An escalation policy must have at least one escalation rule. You can add more rules by clicking on the **Add escalation rule** link. An escalation rule consists of: * A **target**: an individual user, a team or a schedule. If the target is a schedule, the user on-call at the time of the alert assignment will be added as a responder to an alert. If an alert occurs during a time with no coverage in your schedule, then the alert will be escalated immediately to the next escalation level, without waiting for the escalation timeout. If no one is on-call on the entire escalation policy, no one will be notified. * An **escalation timeout**: the amount of time that a responder has to accept an alert until it is automatically escalated to the next escalation level.
An escalation policy detail view. It lists the owning team, the alert sources using the policy, and its routing keys, then shows the escalation rules as a numbered chain: an on-call schedule at level one escalating after 10 minutes, two named responders at level two escalating after 15 minutes, and a final rule stating the policy does not repeat.

Each level names its target and the time the previous level had to respond. Used in lists every alert source relying on this policy.

{% hint style="info" %} **Alerting multiple users at the same time** A single escalation level can hold several targets, and they are all notified at once. How many depends on your plan; the limit is shown inline on the escalation rule when you edit the policy. {% endhint %} ## Delayed escalation With delayed escalation, you can delay escalation by a set period of time (up to 60 minutes). That way, you can avoid getting paged for alerts that quickly resolve themselves. When an alert is created and resolved before the defined delay has passed, ilert won't notify anyone. You can still have those alerts posted somewhere (e.g. Slack) by creating an alert action that gets triggered when an alert is created.
The delayed escalation control at the top of an escalation policy, setting how long ilert waits before notifying anyone.

Set a delay at the top of an escalation policy

## Routing key (optional) By default, an alert source is associated with a single escalation policy and always uses the same policy for every alert that it creates. An escalation policy's routing key can be used in the Events API to overwrite an alert source's escalation policy and route alerts dynamically based on the escalation policy's routing key. You can define multiple routing keys in an escalation policy by separating them with commas in the routing key field. The Events API also accepts multiple routing keys in the `routingKey` field when separated by commas and evaluates them from left to right. The first routing key that matches an escalation policy will be used. If no routing key matches, ilert uses the escalation policy assigned to the alert source. You can also extract the routing from the alert payload using a [routing key template](/alerting/configure-alerting/alert-sources.md#dynamic-escalation-policy-routing). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ilert.com/on-call-management-and-escalations/escalation-policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.