> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Escalation Rules
> Configure alert escalation rules to ensure incidents are promptly notified to the right responders
Escalation rules determine **when**, **through which channels**, **to whom**, and **how to escalate on timeout** when an incident occurs. Through direct messaging, group chat, and multi-level escalation mechanisms, they ensure important incidents always get a response.
## Configuration Elements
An escalation rule contains six core elements. The system matches rules from top to bottom, **stopping after the first successful match**.
You can enable or disable individual escalation rules. Disabled rules are skipped during matching and will not trigger notifications. You can also copy an escalation rule to the current channel or another channel to quickly reuse existing configurations.
### Copy an Escalation Rule
Each escalation rule card shows a **Copy** icon on hover. Clicking it opens the copy dialog (the same component used for copying silence rules), which contains:
| Field | Description |
| :-------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Rule name** | Required; pre-filled with "Copy " plus the original name, **39 characters max** (the backend limit is 40) — overlong input is truncated in the field |
| **Channel** | Choose **This channel** or **Another channel**. Copying to another channel requires picking the target from a dropdown that excludes the source rule's channel; non-admin users only see channels they manage |
| **Description** | Optional; pre-filled with the original description, **500 characters max** — overlong input is truncated in the field |
* The copy reuses the source rule's full configuration (trigger conditions, notification targets, notification methods, delay window, notification template, and escalation levels), but the **priority (list matching order) is not copied** — reposition the new rule in the list after copying
* Copying to the current channel makes the new rule appear in the list immediately; copying to another channel shows the **Copy succeeded** result dialog with the target channel, rule name, description, and creator. Click **Go to view** to open the target channel and locate the new rule
### 1. Trigger Conditions
Determines which incidents trigger the current rule.
**Effective Time**: Controls when the rule participates in matching.
* **Off (Default)**: Active 24/7
* **On**: Only participates in matching within specified time ranges; incidents outside this time will skip this rule. Two modes supported:
* **Specific Time Period**: e.g., only active on weekdays (Monday-Friday 9:00-18:00)
* **Service Calendar**: Reference a predefined [Service Calendar](/en/on-call/configuration/service-calendar), e.g., only active on "Trading Days", automatically excluding holidays
**Incident Filter**: Controls which incidents the rule matches.
* **Off (Default)**: All incidents may match this rule
* **On**: Only incidents matching the filter conditions hit this rule; unmatched incidents continue matching subsequent rules. You can add multiple condition groups — conditions within a group are ANDed, groups are ORed; each condition supports **Match** / **Not Match** operators, with available keys:
* **Integration Source (First Alert)**: Match by the integration that produced the incident's first alert; options are the integrations available to the current channel (both shared and dedicated)
* **Severity**: Multi-select Critical / Warning / Info
* **Title**, **Description**: Support exact, wildcard, regex, CIDR, and numeric comparison matching modes
* **Labels**: Match by alert label key-value pairs (e.g., `service=payment`); keys can be loaded dynamically from recent alert data or entered manually
### 2. Notification Recipients
Determines who receives notifications.
| Recipient Type | Description |
| :------------------------- | :------------------------------------------- |
| **Schedule (Recommended)** | Assign to currently on-call personnel |
| **Team** | Assign to all members of a team |
| **Individual** | Assign to specific personnel |
| **Combination Mode** | You can select multiple types simultaneously |
For dynamic routing to owners based on alert content (e.g., auto-assign based on `owner` label), refer to [Dynamic Assignment](/en/on-call/advanced/dynamic-notifications).
### 3. Notification Methods
Determines how users are reached.
Point-to-point messaging to specific assignees, supports phone calls, SMS, email, app push, IM direct messages (Feishu/Lark, Dingtalk, WeCom, Slack, Microsoft Teams).
* **Follow Personal Preferences (Recommended)**: Notification methods configured by members in [Personal Settings](/en/on-call/configuration/personal-settings)
* **Follow Unified Settings**: Enforce notification methods (e.g., must send SMS), overriding member personal preferences
Send to instant messaging groups, with support for @ mentioning relevant personnel.
* **IM App Groups**: Supports Feishu/Lark, Dingtalk, WeCom, Slack, and Microsoft Teams groups (WeCom is only available for existing configurations and cannot be selected when creating new rules), requires completing [IM Integration](/en/on-call/integration/instant-messaging/lark) first. The group-chat picker automatically excludes platform-created chats such as war rooms (placeholder: "Select … group chat (war rooms excluded)"); stale targets render as **Chat unavailable** and can be removed
* **Group Bots**: Supports Feishu/Lark, Dingtalk, WeCom, Slack, Telegram, Zoom, and other Webhook bots. Telegram requires configuring a Webhook notification address and Chat IDs, Zoom requires configuring a Webhook address and Verify Token, and supports enabling @ mention functionality. See [Notification Channel Configuration](/en/on-call/configuration/notifications)
**Don't use any of the above IM platforms?** You can select any bot type and set the webhook URL to your own server endpoint (the system does not validate domains), then implement the corresponding message protocol on your server. See [FAQ](/en/on-call/quickstart/faq#custom-bot-notifications).
**Cross-team webhook address scoping.** When selecting a Webhook bot address in a dispatch policy, addresses are grouped by ownership tier: **Current Channel** (already referenced by this channel), **Same Team** (referenced by other channels in the same team), and **Other Team** (referenced only by channels in other teams). Other-team addresses are collapsed by default and require manual expansion. Selecting an other-team address shows a **Cross-team** badge and warning; on save, a confirmation modal appears when cross-team addresses are present, preventing alerts from being sent to another team's chat by accident.
When selecting or pasting a Webhook address from **Other Team**, the alias automatically gets a prefix of the source team name (e.g. `team-name-alias`; if an existing alias already starts with that prefix, it is not applied again, and when pasting, the prefix is added only if the alias is empty). After the prefix is added, the alias can still be modified manually.
### 4. Delay Window
Reserve a waiting period before the first notification is sent, to filter out incidents caused by transient flapping.
* Range: 0 – 3600 seconds, default `0` (disabled, notify immediately)
* During the delay window, if the incident is **auto-closed** or **manually closed**, the system does not send a notification
For easily self-healing monitors (such as transient flaps or brief network timeouts), setting a reasonable delay window can significantly reduce unnecessary interruptions.
### 5. Notification Template
Every escalation rule **must** select a notification template, which determines the message format delivered to each channel.
* Templates must be created and enabled in advance under [Notification Templates](/en/on-call/configuration/templates)
* You can pick different templates for different escalation rules to format messages for specific scenarios
### 6. Escalation Rules
This is the key mechanism for ensuring incident closure. When first-level responders don't respond or complete handling, the system automatically escalates to the next level.
**Loop Notification**:
In each escalation level, you can enable the **Loop Notification** feature. When enabled, if the incident is not resolved at the current level, the system sends repeated notifications at the configured interval (minimum 0.5 minutes, in 0.5-minute increments) up to the specified maximum number of times.
**Escalation Conditions**:
* **Not closed**: Incident not closed within N minutes after trigger
* **Not closed and not acknowledged**: Incident neither closed nor acknowledged within N minutes after trigger
The minimum escalation timeout is 1 minute.
**Typical Scenarios**:
| Scenario | Escalation Path |
| :------------------------ | :------------------------------------------------------------------------------------- |
| Level 1 → Level 2 | Level 1 on-call (SRE) no response for 15 min → Escalate to Level 2 development experts |
| Primary/Backup Escalation | Primary on-call no response for 10 min → Escalate to backup on-call |
| Tiered Reporting | Technical staff unresolved for 30 min → Escalate to Tech Lead → Escalate to CTO |
**Level management**:
* **Default first level**: when you create a rule, the first level is generated automatically, with a default **30-minute timeout** before escalation, **no repeated notifications**, and notification methods that **follow personal preferences**
* **Add or remove levels**: you can add or remove levels freely; a rule must keep at least 1 level
* **Reorder**: you can move a level up or down, or insert a new level between any two existing levels
## Best Practices
Recommend keeping a default policy **without filter conditions** at the bottom of the list, assigned to the SRE team or administrators, to prevent incidents from being missed due to filter rule misconfigurations.
* For low-priority `Info` / `Warning` level alerts, recommend using only IM messages, not phone calls or SMS
* Use the **Loop Notification** feature cautiously to avoid alert bombardment
Don't try to manage all company alerts in one channel. Splitting channels by functional module or team, with each channel maintaining independent and simple escalation rules, is key to reducing maintenance costs.
## FAQ
Go to Incident Details → **Timeline** to check if notification status is normal for each channel. If there are failure messages, use them for troubleshooting. Contact technical support for more issues.
Flashduty On-call direct messaging supports two modes: "Follow Personal Preferences" and "Follow Unified Settings". Only in "Follow Personal Preferences" mode will the system send notifications according to your personal settings.
Go to Channel Details → **Escalation Rules** to check current settings.
These are two different features — do not confuse them:
* **Webhook integrations** ([Alert Webhook](/en/on-call/integration/webhooks/alert-webhook), [Incident Webhook](/en/on-call/integration/webhooks/incident-webhook)): When alerts or incidents change, Flashduty pushes event data to your configured URL for integration with external systems (e.g., ticketing systems, automation platforms)
* **Group bot webhooks** (this page, "Notification Methods → Group Chat"): Configure an IM group bot's webhook URL in escalation rules so Flashduty sends incident notification messages to the group chat
In short: webhook integrations are for **data export**, group bots are for **notification delivery**.
## Related Topics
Set rotation rules for automatic assignment
Customize notification time periods and channels
Customize notification content format