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
- In the Flashduty console, go to Channels and open a channel
- Go to Settings → Integrations → Dedicated integrations and click Add an integration
- Select Azure Monitor and click Save
- Open the generated integration card and copy the Push URL
Use a shared integration
- In the Flashduty console, go to Integration Center → Alert Events
- Select Azure Monitor and enter an integration name
- Configure the default route and select a channel; you can add more rules under Routes after creation
- Click Save and copy the generated Push URL
Configure in Azure
Step 1: Create an action group with a webhook
- In the Azure portal, open Monitor, go to Alerts → Action groups, and create an action group
- Under Actions, add an action of type Webhook and enter the push URL copied above as the
URI - Enable the common alert schema and save. Flashduty also parses the legacy Service Health payload when the schema is off; the difference is described under “Title and description” below
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.
Step 2: Create a Service Health alert rule
- In the Azure portal, select Service Health and, in the Service Issues panel, click Create service health alert
- Under Scope, choose the scope by subscription
- Under Condition, select Services, Regions and Event types (service issues, planned maintenance, health advisories, security advisories). Azure recommends selecting all services and all regions: Service Health only triggers alerts for events that affect the regions where your services run, so nothing fires for services you do not use
- Under Details, select the resource group and enter an alert rule name
- Click Advanced options, select the action group from Step 1 on the Actions tab, and create the rule
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.trackingIdare 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
CompleteorCanceledstage; 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
URIis the full push URL, includingintegration_key - Several alerts appear: different Azure events have different Tracking IDs and each gets its own alert; progress notifications of one event merge