A notification policy defines the rules for matching, grouping, notification, and escalation of alerts and events, enabling flexible alert dispatch and notification management.
Features
A notification policy is a core component in the alert and event processing workflow and supports the following features:
Define matching rules for events to select which events to process.
Configure event grouping rules to reduce notification fatigue.
Specify notification targets and notification periods.
Configure repeat notifications, escalation policies, and recovery behavior.
Associate action integrations to enable automated processing.
Create a notification policy
Notification policies are located in Alert Center > Notification Management > Notification Policy. A notification policy defines the entire processing path for an alert, from generation to delivery to a person or system. The policy is configured using a step-by-step wizard that divides the notification process into four stages:
Stage | Description |
Event subscription | Defines the filter conditions for events. Only events that match the subscription conditions enter the notification workflow, ensuring you receive only relevant notifications. |
Notification configuration | Includes three sub-modules: alert grouping and deduplication, routing rules, and notification templates. Alert grouping and deduplication reduces redundant notifications, routing rules dispatch events to different notification targets and channels, and notification templates control the notification content format. |
Repeat/escalation/recovery policy | Controls the lifecycle behavior of an alert, including recovery notifications, auto-recovery time limits, repeat notification frequency, and escalation policies. |
Action integration | Automatically executes predefined actions when an alert is triggered or recovers, such as calling a webhook, triggering Function Compute, or creating an ITSM ticket. |
Notification policies and alert rules have a many-to-many relationship: a single notification policy can be referenced by multiple alert rules, and a single alert rule can use multiple notification policies. When a notification policy is modified, the changes take effect immediately for all alert rules that reference it.
Log on to the Cloud Monitor 2.0 console, select the target workspace, and in the left-side navigation pane, choose .
On the notification policy list page, click Create Notification Policy in the upper-right corner.
On the Create Notification Policy page, first enter the basic information for the policy (name and description), and then complete the four configuration stages in the wizard.
Basic information | Description |
Name (Required) | The name of the notification policy. We recommend using a name that reflects its business purpose, such as "Production-P0/P1-SRE-On-call-Notifications". |
Description (Optional) | Additional information about the notification policy to help your team understand its purpose. |
Step 1: Event subscription
Event subscription defines which events the notification policy should monitor. Only events that match the subscription conditions enter the notification workflow. If you do not configure any conditions, the policy receives all events generated by the alert rules to which it is attached.
Match mode
Event subscription supports three condition matching modes:
Match mode | Description |
Any | An event matches if it meets any of the conditions (OR logic). |
All | An event matches only if it meets all the conditions (AND logic). |
Complex | Use a custom expression to flexibly combine conditions, such as |
Filter conditions
Each filter condition consists of three parts: a field, an operator, and a value.
Parameter | Description |
Field | Select the event field to match, including alert level, alert source, alert title, service name, resource type, cluster name, namespace, and tag. |
Operator | Supported operators include: IN, NOT IN, Equals, Not Equals, Contains, Not Contains, and Matches Regex. |
Value | The system provides a list of candidate values based on the selected field. For some operators, such as Matches Regex, you must enter the value manually. |
You can add multiple filter conditions. When using the "Complex" match mode, you must enter a complex expression in the input box to define the logical relationship between the conditions.
Conditions are automatically numbered in the order they are added (Condition 1, Condition 2, and so on). Use these numbers to reference the conditions in your complex expression. For example, (1 AND 2 AND 3) OR (4 AND 5) means the event must meet all of Conditions 1, 2, and 3, or both of Conditions 4 and 5.
Advanced subscription settings
Click "Advanced Subscription Settings" to expand more configuration items. The following advanced option is currently available:
Parameter | Description |
Global subscription | Select the workspace scope. If you have multiple workspaces, you can configure the notification policy to subscribe to events from specific workspaces for centralized notification management. |
Step 2: Notification configuration
The notification configuration stage includes three sub-modules: alert grouping and deduplication, routing rules, and notification template settings. These modules work together to handle the complete notification process, from event aggregation and dispatch to content formatting.
Alert grouping and deduplication
Alert grouping and deduplication aggregates events with the same dimensions into a single group by using specified fields. This prevents repeated notifications for a large number of similar events in a short period.
Configure grouping fields
Add one or more grouping fields. The system groups events that have identical values in these fields, then processes each group for notification. Common grouping fields include:
Field | Description |
| Alert rule ID. Groups events by rule, so that multiple events from the same rule are included in a single notification. |
| Resource entity ID. Groups events by resource, so that multiple alerts from the same resource are included in a single notification. |
| alert name. Groups events by name. |
| service name. Groups events by service. |
| cluster name. Groups events by cluster. |
| namespace. Groups events by namespace. |
You must configure grouping fields before defining routing rules, as these rules operate on the event groups you create.
Routing rules
Routing rules determine which notification targets receive the event, which notification channels are used, and during which time periods the rule is active. You can configure multiple routing rules. The system matches events against the rules sequentially in the order they appear in the list.
Routing condition
Each routing rule can have a routing condition to limit its scope:
Unconditional: No conditions are set. All events match this rule. This is suitable for a catch-all rule.
Match by condition: Set condition fields and a match mode (All / Any). Only events that meet the conditions match this rule. Available condition fields include alert level, alert source, alert title, service name, and resource type. The available condition fields are limited to those selected for alert grouping and deduplication.
Recipients
For each routing rule, you must specify one or more notification targets and their corresponding notification channels:
Parameter | Description |
Recipient type | Select the recipient type: contact group, contact, or on-call schedule. |
Target recipient | Select the specific contact group, contact, or on-call schedule. |
Notification channels | Select the channels through which the recipient receives notifications. You can select multiple options: Phone, SMS, and Email. IM notification channels (DingTalk, Feishu, WeCom) are configured at the alert rule level. |
You can add multiple notification targets to a single routing rule to notify multiple teams or individuals simultaneously for the same event.
Effective time
You can configure an effective time period for each routing rule:
Time range: Set the daily effective time period (for example, 00:00 to 23:59) and the time zone.
Effective days: Select the days of the week when the rule is active. For example, selecting only Monday to Friday means the rule is active on weekdays.
By configuring effective times for multiple routing rules, you can implement time-based routing, such as notifying Team A on weekdays and an on-call schedule on weekends. Placing a catch-all rule (set to Unconditional) at the end of the list ensures that all events are routed to a notification target.
Notification templates
Notification templates define the content format of alert notifications. You can configure different templates for different notification channels to adapt to the display capabilities of each channel.
Parameter | Description |
Notification channel | Select the channel to which the template applies: Phone, SMS, Email, DingTalk, Feishu, or WeCom. |
Template | Select a pre-existing notification template. The system provides default templates, and you can also select custom ones. |
You can add multiple template configurations to assign different templates to different channels. If a template is not configured for a channel, the system uses the default alert template for that channel.
To create a custom notification template, click the "Create Notification Template" link to go to the template management page. For detailed instructions, see Notification Templates.
Step 3: Repeat, escalation, and recovery
In this stage, you configure the alert lifecycle management behavior, including recovery notifications, auto-recovery, repeat notifications, and escalation policies.
Recovery notification
Configure whether to send a recovery notification to recipients when an alert recovers:
Option | Description |
Send recovery notification | Automatically sends a notification when an alert recovers, informing relevant personnel that the issue is resolved. We recommend enabling this to help teams stay aware of alert status changes. |
Do not send recovery notification | No notification is sent when the alert recovers. This is suitable for low-priority scenarios where the recovery status does not need to be tracked. |
Auto-recovery
Define whether an alert should automatically switch to a recovered state when no new events are received:
Option | Description |
Alerts do not auto-recover | If an event that triggered an alert expires and the issue is not resolved, the alert does not automatically recover. It must be closed by a new recovery event or by manual intervention. |
Timed auto-recovery | After a specified period (in minutes, hours, or days) with no new trigger events, the alert is automatically marked as recovered. This is suitable for scenarios where the event source does not send recovery signals. |
Note: Timed auto-recovery is only intended for scenarios where the event source does not send its own recovery events (for example, a third-party integration). If your alert rule can detect the recovery status, we recommend selecting "Alerts do not auto-recover" and relying on recovery events generated by the rule.
Repeat notification
Control whether to send repeat notifications if an alert remains unresolved:
Option | Description |
Do not repeat notifications | A notification is sent only when the alert is first triggered. No repeat notifications are sent if the alert remains unresolved. This is suitable for scenarios where other tracking mechanisms are already in place. |
Repeat notifications at intervals | If an alert is not resolved, a notification is sent repeatedly at a specified interval (in minutes, hours, or days) to remind relevant personnel. This is recommended for high-priority alerts. |
Escalation policy
Select a pre-existing escalation policy to automatically escalate notifications to higher-level responders if an alert is not acknowledged within a specified time.
Escalation policies must be created in advance under "Notification Management > Escalation Policy". If you do not need this feature, select "None". For detailed instructions on configuring escalation policies, see Escalation Policies.
Step 4: Action integration
Action integration automatically executes predefined actions when an alert is triggered or recovers, enabling a closed-loop, automated process for handling alerts. This feature is disabled by default and must be enabled manually.
After enabling action integration, you can configure actions for the following two trigger points:
Trigger | Description |
On Trigger | Actions that are automatically executed when an alert is triggered. Typical use cases include pushing messages to a DingTalk, Feishu, or WeCom group via webhook; triggering auto-scaling with Function Compute; or calling an HTTP callback to trigger custom processing logic. |
On Recovery | Actions that are automatically executed when an alert recovers. Typical use cases include sending a recovery notification to a group chat, triggering a resource scale-in, or closing an ITSM ticket. |
Available action targets include:
webhook (for IM notifications to DingTalk, Feishu, WeCom, etc.)
HTTP callback (for custom endpoints)
Function Compute (for auto-scaling, service restarts, etc.)
ITSM (for creating a ticket)
Action targets (such as webhooks, Function Compute, and HTTP callbacks) must be created and configured in Integration Management. In the action integration step, you can only select existing action targets; you cannot create new ones.
Associated alert rules
When you create or edit a notification policy, the "Associated alert rules" section at the bottom of the page lists all alert rules that are currently using this policy. You can click an alert rule name to view its details.
This section is read-only. To associate a notification policy with an alert rule, you must do so from the alert rule's configuration page.
Edit notification policy
After you create a notification policy, you can modify its configuration at any time.
In the notification policy list, find the policy you want to modify and click its name or the "Edit" button in the Actions column.
On the edit page, you can modify the configuration for all four stages. Use the step navigation bar at the top to quickly jump to any stage.
After you finish, click "OK" to save your changes.
Changes to a notification policy take effect immediately for all alert rules that reference it. If the policy is shared by multiple alert rules, carefully assess the impact of your changes before saving.
FAQ
Q: Notification policy vs. alert rule
A: An alert rule defines "what conditions trigger an alert," while a notification policy defines "how to notify when an alert is triggered." An alert rule sends notifications by referencing a notification policy. An alert rule can reference multiple notification policies, and a notification policy can be shared by multiple alert rules.
Q: Routing rule match order
A: Routing rules are matched sequentially in the order they are listed. An event can match multiple routing rules, and all matched rules will take effect (they are not mutually exclusive). We recommend placing more specific rules at the top and a general catch-all rule (with the condition set to "Unconditional") at the bottom.
Q: Repeat notifications and escalation policies
A: Yes. Repeat notifications are sent to the original recipients at a fixed interval, while an escalation policy notifies higher-level personnel if the alert is not acknowledged after a certain period. The two features work independently and do not conflict. You can configure both to ensure that alerts are not missed.
Q: Managing action integration targets
A: Action targets (such as webhooks, Function Compute, and HTTP callbacks) are created and maintained in Integration Management. In the action integration step of a notification policy, you can only select existing action targets; you cannot create new ones.