> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Escalation policies

> Page a ladder of channels, level by level, when an aiAxonIQ incident stays unacknowledged — how levels are timed, what stops them, and the limits.

An escalation policy is a ladder of notification channels. When an incident
stays **unacknowledged**, aiAxonIQ pages the first level's channels after its
delay, then the next level's after a further delay, and so on until somebody
acknowledges the incident, it resolves, or the ladder runs out. Policies live
under **Govern → Alerts → Escalation policies**.

Without one, an incident that opens at 03:00 and is never acknowledged looks
exactly like one that was handled. The escalation policy is what acts on that
difference.

<Info>
  **Reading policies needs any role. Creating, editing and deleting them needs
  the Editor role or higher.** See [Roles and permissions](/concepts/roles).
</Info>

## Prerequisites

* At least one **notification channel** connected under **Manage →
  Integrations** — Slack, Microsoft Teams, PagerDuty, Opsgenie or Email. A level
  can only page a connected channel. See [Integrations](/guides/integrations/overview).
* Incidents being opened — by alert rules, synthetic checks or security
  detections. See [Incidents](/guides/incidents/overview).

## How escalation works

### One enabled policy per organization

Only **one** policy can be enabled at a time, and it applies to **every** open
incident in the organization, whatever its source or severity. Trying to enable
a second is refused — disable the current one first. You can keep any number of
disabled policies.

<Note>
  Policies cannot be scoped to a service, a rule or a severity. If you need
  different ladders for different problems, that is not possible today; route
  the *initial* notification per rule instead, and use the policy as the
  organization-wide safety net.
</Note>

### Levels

A policy has **1 to 10 levels**. Each level has:

* a **wait** — between 1 second and 7 days — and
* **1 to 10 channels** to notify, each named once.

Levels are numbered 1, 2, 3… with no gaps. The waits **add up**: a policy of
*5 minutes* then *10 minutes* pages level 1 at 5 minutes and level 2 at 15
minutes. Level 1's wait is measured from when the incident was first seen.

Each level pages **once**. After the last level, nothing further is sent — a
policy does not repeat.

### What "unacknowledged" means

Escalation only advances an incident whose status is **`OPEN`**. It stops the
moment the incident is:

* **acknowledged** — somebody pressed **Acknowledge**, or
* **resolved** — by hand, or automatically when an alert rule's condition
  clears.

<Warning>
  **Assigning an incident does not stop escalation.** Assignment says who
  *should* look; acknowledgement says somebody *is*. An incident assigned to
  someone asleep keeps escalating until it is acknowledged — that is the silence
  escalation exists to break.
</Warning>

### What an escalation sends

The escalation is an ordinary notification to the level's channels. Its title
is the incident's title prefixed with `[ESCALATION L<level>]`, and it carries
the incident's **original severity** — escalating changes who is told, not how
bad the problem is.

Each escalation is recorded on the incident's timeline as **Escalated**, with
the level, before any channel is attempted — so the record exists even if every
channel fails.

Because it is an ordinary notification, an escalation:

* is **withheld by maintenance windows and silences** that cover it — escalation
  is not an override (see [Silences and maintenance windows](/guides/alerts/silences-maintenance));
* is subject to the notification **rate limit** of 60 notifications per channel
  per minute, from which `CRITICAL` notifications are exempt;
* is retried like any other delivery if the channel fails temporarily.

### Timing

Escalation is checked **once a minute**, so a level can go out up to about a
minute after its due time.

Enabling a policy, or changing its levels, **restarts the clock from now** for
incidents that are already open. Without that, enabling a 5/10/15-minute policy
beside a half-hour-old incident would fire all three levels in three minutes.
Renaming a policy or changing its description does not move the clock. The
policy list shows each policy's current timing anchor — the moment its clock
last started.

When a newly enabled or edited policy picks up incidents that were already
open, their first escalation is spread over about **ten minutes**, so a large
backlog does not all page in one instant and trip the rate limit. Incidents
that open *after* the policy keep their exact schedule.

<Note>
  **Escalation runs where alert evaluation runs.** It is part of the same
  background process as the alert loop, so wherever alert rules are being
  evaluated, escalation is running too — and on a self-hosted deployment where
  alert evaluation is turned off, escalation stops with it.
</Note>

## Create a policy

<Steps>
  <Step title="Connect your channels">
    Make sure every destination you want on the ladder exists under **Manage →
    Integrations**, and use **Send test** on each one.
  </Step>

  <Step title="Open Escalation policies">
    Go to **Alerts → Escalation policies** and create a new policy. Give it a
    name (for example *Production on-call*) and an optional description.
  </Step>

  <Step title="Build the ladder">
    For each level set **Wait before this level** and choose its **Channels**.
    The form shows when each level will page, measured from when the incident
    opened.
  </Step>

  <Step title="Enable it">
    Leave **Enabled** on. If another policy is already enabled, disable that one
    first.
  </Step>
</Steps>

The Escalation policies page shows **Enabled policy**, **Levels** and
**Destinations** at the top. If it reads **Nothing is escalating**, no policy is
enabled and unacknowledged incidents will sit unacknowledged indefinitely —
nothing else reports this.

## Editing and deleting

An edit replaces the whole ladder at once — there is no partial edit of one
level — and no incident ever sees a half-saved policy. Remember that changing
the ladder restarts the clock for open incidents.

Deleting or disabling a policy stops all escalation immediately; incidents
already escalated keep their timeline entries.

<Warning>
  **Removing a connected channel that a level names stops that level from
  paging anyone.** If any channel named on a level no longer exists, the whole
  level fails and nobody on it is notified — aiAxonIQ does not quietly page the
  remaining channels, because a partial page looks like a working one. The
  level is not retried. After removing a channel under **Integrations**, edit
  every policy level that named it.
</Warning>

## Verify it works

<Steps>
  <Step title="Build a short test ladder">
    Create a policy with one level, a 1-minute wait, and a channel you can watch.
    Enable it (disable your production policy first, or do this in a
    non-production organization).
  </Step>

  <Step title="Open an incident and leave it alone">
    Make an alert rule fire and do **not** acknowledge the incident.
  </Step>

  <Step title="Watch it escalate">
    Within about two minutes the channel receives an `[ESCALATION L1]` message,
    and the incident's timeline shows **Escalated** with level 1.
  </Step>

  <Step title="Confirm acknowledgement stops it">
    Repeat with a two-level policy and acknowledge after level 1. Level 2 never
    arrives.
  </Step>
</Steps>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Nothing escalated">
    * **No policy is enabled.** The page says *Nothing is escalating*.
    * **The incident was acknowledged or resolved** before the level was due —
      including automatically, when an alert rule's condition cleared.
    * **The clock restarted.** Enabling the policy or changing its levels after
      the incident opened restarts timing from that moment, plus up to ten
      minutes of spreading.
    * **The notification was withheld** by a maintenance window, a silence or
      the rate limit. The *Escalated* timeline entry is still written.
    * **A channel on the level was removed.** See the warning above.
  </Accordion>

  <Accordion title="The server refused my policy">
    Common reasons: no levels; more than 10 levels or 10 channels on a level; a
    wait outside 1 second to 7 days; the same channel twice on one level; a
    channel that does not belong to this organization; or another policy is
    already enabled (`ALREADY_ENABLED`).
  </Accordion>

  <Accordion title="An assigned incident keeps paging">
    Expected. Only acknowledging (or resolving) stops escalation.
  </Accordion>

  <Accordion title="Everyone got paged at once after I enabled a policy">
    Incidents that were already open become due relative to when you enabled
    the policy, spread over about ten minutes. With many open incidents on one
    channel the rate limit can still withhold some. Resolve stale incidents
    before enabling a policy.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Incidents" icon="fire" href="/guides/incidents/overview">
    Acknowledge, assign and resolve.
  </Card>

  <Card title="Integrations" icon="plug" href="/guides/integrations/overview">
    Connect the channels a level pages.
  </Card>

  <Card title="Silences and maintenance windows" icon="bell-slash" href="/guides/alerts/silences-maintenance">
    What withholds an escalation.
  </Card>

  <Card title="Alerting" icon="bell" href="/guides/alerts/overview">
    Rules that open incidents.
  </Card>
</CardGroup>
