> ## Documentation Index > Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt > Use this file to discover all available pages before exploring further. # Alibaba CloudMonitor 2.0 Notification Policy Edition integration > Send issue trigger, update, and recovery notifications to Flashduty On-call using CloudMonitor 2.0 notification policies and the system default Webhook template. Send issue notifications from Alibaba Cloud Monitor 2.0 notification policies to Flashduty On-call. ## Differences from other Alibaba Cloud integrations Choose the integration that matches the notification entry point in Alibaba Cloud. | Notification method in Alibaba Cloud | Flashduty integration | | - | - | | CloudMonitor 2.0 → Alert center → Notification policy → Custom Webhook | **Alibaba CloudMonitor 2.0 Notification Policy Edition**, covered by this guide | | CloudMonitor 1.0 cloud product metric alert callbacks | [Alibaba Cloud CM metrics](https://docs.flashduty.com/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-metrics.md) | | Cloud product system event callbacks | [Alibaba Cloud CM events](https://docs.flashduty.com/en/on-call/integration/alert-integration/alert-sources/aliyun-cm-event.md) | | Direct callbacks from ARMS or Prometheus monitoring | [Alibaba Cloud ARMS](https://docs.flashduty.com/en/on-call/integration/alert-integration/alert-sources/aliyun-arms.md) or [Alibaba Cloud Prometheus monitoring](https://docs.flashduty.com/en/on-call/integration/alert-integration/alert-sources/aliyun-prometheus.md) | Notification policies group related events into an Alibaba Cloud issue. The system default Webhook template sends `incidentId`, `title`, `state`, `severity`, and `events[]`. Use this integration whenever that policy sends the notification, including events from ECS, Prometheus, or APM. Each notification produces one Flashduty alert event, with `incidentId` as its Alert Key (`alert_key`). Child events in `events[]` supply descriptions and labels; they are not split into separate alerts. Subsequent notifications with the same `incidentId` use the same correlation key. Flashduty alert processing rules still determine incident creation and grouping. > [!WARNING] > > This integration supports only Alibaba Cloud's **system default Webhook notification template**. Keep both Chinese and English content unchanged. Custom templates and added, removed, or renamed fields are unsupported. If you edited a template, select **Restore default** in the Alibaba Cloud template editor and save. Individual CloudEvents events and custom JSON are unsupported. ## In Flashduty On-call Use either method below to obtain the integration push URL. ### Use a dedicated integration Choose this method to send alerts to one channel. > [accordion] View dedicated integration setup steps > > 1. In the Flashduty console, select **Channels** and open the target channel. > 2. Go to **Configuration → Integrations → Dedicated integrations** and select **Add integration**. > 3. Select **Alibaba CloudMonitor 2.0 Notification Policy Edition** and save. > 4. Open the integration card and copy the **Push URL**. ### Use a shared integration Choose this method to route alerts to different channels based on their content. > [accordion] View shared integration setup steps > > 1. Go to **Integration center → Alert events**. > 2. Select **Alibaba CloudMonitor 2.0 Notification Policy Edition** and enter an integration name. > 3. Configure a default route and select a channel. > 4. Save and copy the **Push URL**. Add more rules under **Routing** after creation. ## Configure Alibaba Cloud **1. Create a custom Webhook notification object** Sign in to the [CloudMonitor 2.0 console](https://cmsnext.console.aliyun.com) and select the target workspace. Go to **Alert center → Notification management → Notification objects → Custom Webhook** and create an object. | Setting | Value | | - | - | | Name and identifier | Use a recognizable name such as `Flashduty`; the identifier must be unique | | URL | `{integration_url}` | | Headers | `Content-Type`: `application/json` | | Method | `POST` | | Data format | `JSON` | | Language | Chinese or English, matching the notification template language | Save the object. Use the complete push URL generated by this integration. ARMS, Prometheus, and CM metrics integration URLs use different formats. **2. Configure the notification policy and default template** Go to **Alert center → Notification management → Notification policies** and create or edit the target policy. 1. Set matching conditions to select the alerts you want to send. 2. Select **Webhook** as the notification method and choose the object you created. 3. Use the **system default Webhook notification template**. Keep both Chinese and English content unchanged. Do not create custom content. No Flashduty field mapping is needed. 4. Enable recovery notifications and save. Send both trigger and recovery notifications for the same issue to this Webhook. If a template was edited, select **Restore default** in the Webhook template editor for the affected language and save. See Alibaba Cloud's [Notification templates](https://help.aliyun.com/zh/cms/cloudmonitor-2-0/cms-2-0-notification-template) documentation for the template entry point. **3. Verify triggering and recovery** Wait for a real alert matching the policy to trigger. In Flashduty, check the integration's **Latest event time** and confirm that the target channel received the alert. Check the title, severity, resource labels, and detail links. Then resolve the same issue in Alibaba Cloud. Confirm that its recovery notification arrives and uses the same `incidentId` to correlate with the original alert. A successful push in Alibaba Cloud also requires verification of the actual result in Flashduty. ## Status and severity The notification's top-level `state` determines recovery. Child events in recovery notifications may retain their trigger-time status and metric values; these do not affect recovery. | Top-level `state` | Top-level `severity` | Flashduty | | - | - | - | | `triggered` | `CRITICAL`, `ERROR` | Critical | | `triggered` | `WARNING`, `WARN` | Warning | | `triggered` | `INFO` | Info | | `resolved` | Any supported severity above | Ok (recovered) | Default notifications must include `incidentId`, `title`, `startTime`, `subscription`, `severity`, `state`, and `events`. Missing required fields or an invalid state cause rejection; `events` can be an empty array. Restore the system default template instead of adding fields with custom JSON. ## Labels and descriptions The integration reads allowlisted scalar event fields. It does not expand all product fields or nested JSON. Missing fields, conflicting aliases, and ordinary event values over 512 bytes do not produce labels. Detail links can contain up to 8 KiB; longer links are omitted. At most 30 labels are generated, reserving one slot for `events` alongside notification metadata, detail links, and common resource dimensions. | Category | Possible labels | | - | - | | Notification | `cloud`, `incident_id`, `subscription`, `original_severity`, `event_count` | | Selected event JSON | `events` | | Monitoring and rules | `region`, `workspace`, `rule_id`, `rule_name`, `monitoring_source`, `product` | | Business dimensions | `env`, `business`, `team`, `project`, `service`, `app` | | Container and cloud resources | `resource_domain`, `resource_type`, `entity_id`, `cluster`, `cluster_id`, `namespace`, `pod_name`, `workload_name`, `workload_kind`, `instance_id`, `instance_name`, `host`, `ip` | | Product instances | `service_id`, `prometheus_id`, `prometheus_name` | | Detail links | `alert_rule_url`, `alert_history_url`, `generator_url`, `resource_url` | With multiple events, an event dimension becomes a label only when **every child event has the same value**. If two Pods share a namespace but have different names, `namespace` is retained and `pod_name` is omitted. A link shared by only some events is also omitted as the alert-level link. The `events` label stores selected fields as compact JSON, rather than the entire upstream event. It preserves source field names, nesting, types, and event order without parsing nested JSON strings. You can inspect the JSON in the alert labels. | Retained content | Field scope | | - | - | | Current observations | Current statistic values, sample times, trigger times, and alert durations | | Alert conditions | Metrics, severities, thresholds, values, statuses, `idx`, and condition times in `detailValue` | | Query configuration | A reduced `rule.query`: `type`, `expr`, `duration`, and `namespace`, plus ordered `queries` entries containing `measureCode`, `expr`, `duration`, `filters`, and `groupBy` | | APM rules | Rule descriptions that explain the alert conditions | | Distinguishing context | Necessary resource and rule information at its original path when separate labels do not express it, including differences across events, alias conflicts, and label-count limits | Query and condition arrays retain their order and `idx` associations; they are not split arbitrarily. Delivery identifiers, protocol fields, `userId`, notification settings, full rules, extension and sending settings, JVM properties, and duplicate `_cms_val_json` and `reachedPointsJson` data are excluded. Resources, rules, and detail links remain separate labels instead of being repeated in the JSON. The `events` label contains at most 8 KiB. Events with no retained fields after selection are omitted; `event_count` still records the original upstream event count. Normal selection does not set a truncation marker. Only when selected content still exceeds the limit is content omitted and the result wrapped in an object containing `events` and `_flashduty`. It always remains valid JSON. `_flashduty.truncated=true` explicitly indicates additional lossy omissions. This label is not a complete original payload. The description contains only deduplicated summaries from upstream `annotations.message` and `annotations.summary`. It is empty when neither contains text. Summaries are not repeated in `events`; resources and thresholds are not flattened into the description. Detail links use separate labels and must be valid HTTP or HTTPS URLs. The resource tag `instance` may identify a monitoring endpoint. The integration does not automatically treat that endpoint as the affected instance ID. Only valid IP addresses produce the `ip` label. ## FAQ > [accordion] What should I check when a push returns 400? > > Confirm that the URL comes from **Alibaba CloudMonitor 2.0 Notification Policy Edition**. Legacy CM, ARMS, and Prometheus callbacks use different payload formats, so their URLs are not interchangeable. > > Then check that the policy uses the system default Webhook template. Custom templates, individual CloudEvents events, and JSON without `incidentId` are unsupported. Restore the default content and trigger another notification to verify delivery. > [accordion] The alert triggered but did not recover > > Confirm that recovery notifications are enabled and sent to the same Webhook. Compare the top-level `incidentId` and `state` in both notifications. The ID must match, and the recovery state must be `resolved`. Do not use `events[].status` to determine whether the entire issue has recovered. > [accordion] Why is a resource label or detail link missing? > > The field may be outside the allowlist, empty, or different across child events. Check child event context in the `events` label. Do not modify the Alibaba Cloud default template to add fields. > [accordion] Alibaba Cloud did not send a notification > > Check the policy's matching conditions, notification method, and notification object. For private deployment endpoints, also allow network access as described in Alibaba Cloud's [Notification objects](https://help.aliyun.com/zh/cms/cloudmonitor-2-0/notification-object) documentation. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.