No notification sent despite alert firing – Action Group deduplication

Direct Answers

1. Sizing deduplication windows to suppress flapping without hiding persistent alerts

Azure Monitor deduplicates alert instances by rule identity, resource, signal, and dimensions. While an instance remains Active, re‑firings update the same instance and the Action Group is notified only on state transitions (fired → active, active → resolved) by default. To avoid masking a sustained issue:

• Match the alert rule’s evaluation frequency and aggregation window (e.g., evaluate every 5 minutes over a 15‑minute window).
• Require 2–3 consecutive violations before the rule fires.
• Keep Action Group notifications enabled for both fired and resolved states.
• Use Alert Processing Rules to suppress or reroute by scope, severity, or time window instead of relying solely on Action Group suppression.

2. Minimum historical period for dynamic thresholds and interim noise management

• Dynamic threshold detectors need historical data to model normal behavior. At least 7 days of data is the documented minimum; reliability improves after several weeks.
• For new resources, start with a static threshold or a less sensitive dynamic setting (e.g., "Low" sensitivity).
• Route early‑phase alerts to a low‑noise channel (e.g., a dedicated Teams channel) via an Alert Processing Rule, then switch to full dynamic sensitivity after the warm‑up period.
• Review the detector’s history and data‑coverage period in the Azure portal to confirm warm‑up completeness.

3. Balancing ITSM "Only send notifications if resolved" with real‑time awareness

• Create two notification paths:
  • Real‑time awareness – email, Teams, or push notifications on fired (and optionally on resolved).
  • ITSM ticket creation – configure the ITSM connector to trigger only on resolved.
• Implement this split using separate Action Groups and Alert Processing Rules that route fired events to the real‑time group and resolved events to the ITSM group.

Steps for This Case

1. Open the Alerts blade in Azure Monitor and inspect the alert instance timeline: note the Active duration, last fired, and last resolved timestamps.
2. Verify the Action Group is configured to notify on both fired and resolved state changes.
3. Review the alert rule settings: evaluation frequency, aggregation period, number of consecutive violations, and auto‑resolve behavior.
4. Check for any Alert Processing Rules that might suppress or reroute notifications for this rule or resource.
5. For dynamic thresholds, open the rule’s Detector history to see the data‑coverage period and confirm whether the 7‑day minimum has been met.

Verification Commands (Azure CLI)

# List alert history for a specific rule
az monitor alert show --name  --resource-group  --query "history"

# Show Action Group configuration
az monitor action-group show --name  --resource-group 

# List Alert Processing Rules in the subscription
az monitor alert-processing-rule list --query "[].{Name:name, Enabled:enabled, Conditions:conditions, Actions:actions}"

Assumptions & Uncertainty

• Behavior described reflects Azure Monitor as of 2026; dynamic threshold internals can vary by metric and resource type.
• Action Group deduplication logic is based on documented state‑transition notifications; custom webhook receivers may behave differently.
• ITSM connector behavior depends on the specific ITSM tool integration (ServiceNow, etc.).

One Missing Diagnostic Detail

What is the current evaluation frequency and aggregation window of the alert rule? This directly determines the appropriate deduplication window and consecutive‑violation count.