Skip to main content
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.
Reading policies needs any role. Creating, editing and deleting them needs the Editor role or higher. See Roles and permissions.

​
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.
  • Incidents being opened — by alert rules, synthetic checks or security detections. See Incidents.

​
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.
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.

​
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.
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.

​
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);
  • 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.
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.

​
Create a policy

1

Connect your channels

Make sure every destination you want on the ladder exists under Manage → Integrations, and use Send test on each one.
2

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.
3

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.
4

Enable it

Leave Enabled on. If another policy is already enabled, disable that one first.
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.
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.

​
Verify it works

1

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).
2

Open an incident and leave it alone

Make an alert rule fire and do not acknowledge the incident.
3

Watch it escalate

Within about two minutes the channel receives an [ESCALATION L1] message, and the incident’s timeline shows Escalated with level 1.
4

Confirm acknowledgement stops it

Repeat with a two-level policy and acknowledge after level 1. Level 2 never arrives.

​
Troubleshooting

  • 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.
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).
Expected. Only acknowledging (or resolving) stops escalation.
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.

​
Next

Incidents

Acknowledge, assign and resolve.

Integrations

Connect the channels a level pages.

Silences and maintenance windows

What withholds an escalation.

Alerting

Rules that open incidents.