Skip to main content
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 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.
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.
  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.
  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 and select the target workspace. Go to Alert center → Notification management → Notification objects → Custom Webhook and create an object.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 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. 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. 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. 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

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