Azure Monitor vs Azure SQL Database: Dynamic Threshold Support Across All Metrics?

Answer first

Dynamic threshold alerts are metric-specific for Azure SQL Database. As of the 2024-2025 feature set, dynamic thresholds are exposed for a subset of platform metrics such as CPU percentage, DTU percentage, Data IO percentage, Log IO percentage, Storage percentage, Workers percentage and Sessions percentage. Metrics like deadlock count, blocked connections and tempdb usage typically do not expose the dynamic threshold option in the portal.

Suppression can be applied to any metric alert rule, static or dynamic. Suppression is an action rule that silences notifications from an action group during a schedule or after N consecutive triggers. It does not change threshold evaluation; the alert still fires and appears in alert history.

For metrics that only support static thresholds, the cost-effective noise reduction pattern is static threshold + action rule suppression + multi-condition correlation, with periodic recalibration from Azure SQL Intelligent Insights.

Confirmed facts

• Dynamic threshold toggle appears only for supported metrics when creating a metric alert rule in Monitor > Alerts > Create alert rule > Condition tab for a Microsoft.Sql/servers/databases resource.
• Action rule suppression operates at the action group level and can be attached to any alert rule regardless of threshold type.
• Dynamic threshold alerts have no extra per-alert cost beyond standard metric alert pricing; each distinct alert rule counts toward subscription quota and generates evaluation logs.

Likely explanation and assumptions

The list of supported metrics can change with Azure Monitor service updates. The names above reflect the 2024-2025 state and should be verified for your subscription. Suppression silences notifications only; the alert instance is still created and can clutter dashboards if not filtered.

Multi-condition alert rules require all conditions to be evaluated on the same resource and time grain. Mixing metrics with different aggregation granularities, e.g., 1-minute CPU% with 5-minute deadlock count, is not supported.

Steps for this case

1. Verify support for a specific metric. In the portal open Monitor > Alerts > Create alert rule, select the Azure SQL Database resource and open Condition. If Dynamic threshold is visible, the metric supports it. For API verification, inspect metric definitions for Microsoft.Sql/servers/databases and check dynamic threshold eligibility.
2. If dynamic is available, use it for CPU%, DTU%, Data IO%, Log IO%, Storage%, Workers%, Sessions%. Keep evaluation window and sensitivity consistent with workload patterns.
3. If dynamic is not available, create a static threshold rule with a conservative value. Attach an action rule suppression for maintenance windows and for auto-mitigation after N consecutive triggers.
4. Reduce single-metric noise with multi-condition rules where possible, e.g., CPU% > 80 AND Workers% > 70, to avoid spikes from one signal.
5. Periodically recalibrate static thresholds using Azure Advisor and Azure SQL Intelligent Insights recommendations. These are advisory and require manual or scripted updates.

Current verification is required before production use, as dynamic threshold availability is metric-specific and service updates may expand or contract the list.