Skip to main content
Sync Azure Monitor alert events to Flashduty through webhook for automated alert noise reduction.

​
In Flashduty

You can get the integration push URL in either of the following ways.

​
Use a dedicated integration

Choose this option if all alerts go to one channel. It’s the simpler setup.
  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Choose Azure Monitor integration and click Save to generate a card
  4. Open the generated integration card and copy the Push URL

​
Use a shared integration

Choose this option if you need to route alerts to different channels based on the alert payload.
  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Azure Monitor integration:
    • Integration Name: Define a name for this integration
  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

​
In Azure Monitor

Step 1: Configure webhook
  1. Log in to your Azure Portal and select Monitor product;
  2. Go to Alerts -> Action groups page, and click Create;
  3. Select Action type as Webhook under Actions;
  4. Enter a name, copy and paste the integration push URL into the URI field. We recommend that you Enable the common alert schema;
  5. Click Create button to save.
drawingFlashduty also parses Azure’s noncommon payloads when the common alert schema is off: metric alerts, Log Alerts V1 log search alerts (Log Analytics and Application Insights), and activity log alerts. The only unsupported payload is a log search alert with a custom JSON payload. Such a request returns 400; enable the common alert schema instead.Step 2: Configure alert rule
  1. Go to Alerts -> Alert rules page, click Create or select an existing policy to edit;
  2. Select the created Action group on the Actions page; drawing
  3. Save and wait for alerts to trigger.
Metric alerts, log search alerts, Prometheus alerts, Application Insights smart detection, and availability tests are all configured this way. The activity log alerts below are created from their own entry points; select the same Action group.

​
Service health

  1. In the Azure Portal, go to Service Health -> Health alerts and click Create service health alert;
  2. Select the subscription, services, regions, and event types (service issues, planned maintenance, health advisories, security advisories);
  3. Under Actions, select the Action group created above and save.
One Azure event (one Tracking ID) creates one Flashduty alert per subscription, and later updates merge into that alert. The alert recovers when the notification stage (stage) is Resolved, RCA, Complete, or Canceled. With the common alert schema, the alert title is “alert rule name on resource name” (only the rule name for subscription-level rules). Without it, the title is the event title and the description is Azure’s communication text. Labels include tracking_id, stage, incident_type, impacted_services, and impacted_regions, and service_health_url links to the event’s Service Health page.The Service Health sample sent by Test action group is at the Resolved stage, so Flashduty treats it as a recovery and does not create an alert.

​
Resource health

  1. In the Azure Portal, go to Service Health -> Resource health and click Add resource health alert;
  2. Select the resources to monitor. Under event status, select both Active and Resolved, otherwise Azure sends no recovery notification;
  3. Under Actions, select the Action group created above and save.
Each resource maps to one Flashduty alert, with the Alert Key derived from the resource ID (case-insensitive). The alert triggers when the resource becomes unavailable, degraded, or unknown, and later status changes of the same resource merge into it. The alert recovers when currentHealthStatus becomes Available or the activity log status is Resolved. Labels include current_health_status, previous_health_status, health_event_type, health_event_cause, and resource_id.

​
Defender for Cloud security alerts

Defender for Cloud writes its security alerts to the Security category of the activity log. In Alerts -> Alert rules, create an alert rule whose condition is an activity log signal with category Security, and select the Action group created above.With the common alert schema, the alert title is “alert rule name on resource name” and the severity is Info (Azure sends every activity log alert as Sev4). The security alert’s own severity, category, and affected entity are added as the vendor_severity, category, and compromised_entity labels, which you can use in routing or noise reduction rules. Without the common alert schema, the title is the security alert’s description or category plus the affected entity, for example Failed SSH brute force attack on LinuxVM1, and the severity follows the security alert: High maps to Critical, Medium to Warning, and Low and Informational to Info. Each security alert notification creates its own Flashduty alert, which does not recover automatically; close it by hand once handled.

​
Other activity log alerts

Administrative, Policy, Autoscale, and Recommendation activity log alerts are one-shot events: each notification creates one Flashduty alert that does not recover automatically. With the common alert schema, the alert title is “alert rule name on resource name” and the operation goes into the operation_name label. Without it, the payload has no rule name, so the title is “operation on resource”, for example Microsoft.Compute/virtualMachines/restart/action on test-VM.

​
Alert key and recovery

Dimensions of metric and log alerts (for example ApiName or Computer), the metric name metric_name, the query search_query, and the labels of Prometheus alerts all become Flashduty labels. subscription_id, resource_group, and resource_id are parsed from the resource ID.

​
Status mapping

Azure Monitor to Flashduty alert severity mapping:Noncommon metric alerts and Log Alerts V1 express severity as 0 to 4, mapped as above. The Critical, Warning, and Informational values of the legacy Log Analytics alert API map to Critical, Warning, and Info. Azure sends every activity log alert as Sev4 (Info); security alerts sent without the common alert schema follow the security alert severity mapping above.

​
FAQ

  • Azure reports a failed webhook call (400): check whether the log search alert uses a custom JSON payload. Enable the common alert schema and retry.
  • A Service Health alert does not recover: Azure sends a Resolved stage notification when the event is resolved; make sure the alert rule is still enabled. Planned maintenance recovers at the Complete or Canceled stage.
  • A Resource Health alert does not recover: make sure the alert rule’s event status includes Resolved.
  • An alert appears after testing the Action group: except for Service Health, Azure’s test samples cannot be told apart from real alerts, so they create alerts. Close them by hand.
  • A Service Health or Resource Health notification has no Tracking ID or resource ID: with the common alert schema, each such notification becomes its own alert and does not recover automatically.
For field details, see the Azure documentation Common alert schema and Noncommon alert schema definitions.