Skip to main content
Azure writes service issues, planned maintenance, health advisories and security advisories to the activity log as Service Health notifications, and a Service Health alert rule can send them out through an action group webhook. The Flashduty Azure Monitor integration parses Service Health notifications and merges every notification of the same event (same subscription and tracking ID) into one alert, so no separate Azure Service Health integration is needed: create an Azure Monitor integration in Flashduty and paste its push URL into the action group.

In Flashduty On-call

Get an integration push URL in either of the two ways below. Choose the Azure Monitor integration type in both, not Azure Service Health.

Use a dedicated integration

  1. In the Flashduty console, go to Channels and open a channel
  2. Go to Settings → Integrations → Dedicated integrations and click Add integration
  3. Select Azure Monitor and click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Azure Monitor and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure in Azure

1

Create an action group with a webhook in Azure Monitor

Where: Azure portal › Monitor › Alerts › Action groups › CreateOn the Basics tab, fill in Subscription, Resource group, Region, Action group name and Display name (all required); Region must be Global. Then add a webhook action on the Actions tab:Click OK, then Review + create › Create to save.
Azure requires that the action group used by a Service Health alert has its region set to Global; Service Health alerts are only supported in public clouds within the global region.
2

Create a Service Health alert rule

Where: Azure portal › Service Health › Service Issues › Create service health alertClick Create when done.
3

Test the action group and confirm

Where: Azure portal › Monitor › Alerts › Action groups › your action group › TestSelect a sample type and the webhook action, then click Test. A status of Success means Azure called the push URL; if it fails, click View details. The Service Health sample is at the Resolved stage, so Flashduty treats it as a recovery and does not create an alert; to see an alert, wait for a real Service Health event.With the alert rule still enabled, the corresponding alert appears in Flashduty when a real event arrives.

Field mapping

Title and description

With the common schema, the event title and text stay in the JSON of the alertContext label. If you want the event title directly in notifications, use the legacy payload (leave the common alert schema off).

Recovery and deduplication

  • Azure sends several notifications for one Tracking ID as the event progresses, and Flashduty merges them through the Alert Key; the alert recovers when the event reaches a resolved stage
  • Legacy notifications without properties.trackingId are rejected (HTTP 400); with the common schema, a notification without a Tracking ID becomes its own alert and does not recover automatically
  • Planned maintenance recovers in the Complete or Canceled stage; until then, the alert stays triggered

Troubleshooting

  • The action group does not fire: confirm the action group’s region is Global and that the alert rule’s Actions tab has this action group selected
  • The alert does not recover: confirm the alert rule is still enabled and wait for Azure to send the notification for the resolved stage
  • Azure shows the webhook call failed: confirm the URI is the full push URL, including integration_key
  • Several alerts appear: different Azure events have different Tracking IDs and each gets its own alert; progress notifications of one event merge
For field details, see the Azure documentation Create Service Health alerts, Activity log alert webhook schema and Common alert schema.