Azure Policy takes automation further by automatically applying alert rules to every current and future resource of a given type. This ensures that no new virtual machine or storage account escapes monitoring. When you define the alert logic in a policy, the alert rules are created behind the scenes for each resource. No matter which creation method you choose, each alert rule must be associated with at least one action group to define the response—whether that is a notification, an automated task, or both.
Action groups are reusable collections of notification methods and automated actions that execute when an alert fires. Each action group can include email, SMS, push notifications via the Azure mobile app, voice calls, and more advanced integrations such as webhooks, Azure Functions, Logic Apps, Automation Runbooks, and ITSM connectors like ServiceNow. By attaching the same action group to multiple alert rules, you centralize who gets paged and which workflows run, reducing duplicated configuration. A single alert rule can reference up to five action groups, and all actions within those groups run concurrently.
Action groups support an especially useful notification channel: Email Azure Resource Manager Role sends alerts to everyone who holds a specific RBAC role rather than a fixed list of addresses. For SMS and voice, recipients can reply to unsubscribe or resubscribe without leaving the workflow. When you need to suppress notifications during planned maintenance or route alerts to different teams based on severity, you combine action groups with alert processing rules. Because action groups execute in parallel and can be deployed globally or regionally, they remain resilient even if one region experiences an outage. Service limits on email and SMS volume mean that large-scale environments should prefer automation endpoints—such as an Automation Runbook that creates an incident ticket—over human notification channels.
Design and Manage Alert Processing Rules for Advanced Alert Routing
Alert processing rules (formerly called action rules) do not create alerts; they modify the behavior of alerts that have already fired. Their two primary actions are Suppression and Apply action groups. Suppression stops all notifications during a defined window—for example, during a maintenance period—without disabling the underlying alert rules. The Apply action groups action adds extra notification channels to alerts, which is especially useful for older Azure services that do not natively support action groups.
The scope of an alert processing rule can be a single resource, a resource group, or an entire subscription. Within that scope you add Filters to narrow the rule's effect based on criteria such as severity, monitor service, or resource type. Multiple different filters use AND logic, meaning all conditions must match for the rule to apply. Within a single filter, multiple values use OR logic, so a filter monitoring severity can catch both Error and Critical in one condition. When an alert is matched by more than one processing rule, a Suppression action always takes priority over an Apply action group action. This hierarchy prevents conflicting rules from accidentally sending notifications during a suppression window.
Scheduling gives you fine-grained control over when a processing rule is active. You can set it to be Always active, use a One-time window for a specific event, or define a Recurring schedule for weekly maintenance. By combining scope, filters, and scheduling, a single alert processing rule can manage thousands of underlying alert rules. This reduces human error and ensures that high-severity incidents always reach the correct response team, while expected noise from planned work is silently dropped. Administrators can create and manage these rules through the Azure Portal, Azure CLI (az monitor alert-processing-rule), or PowerShell (Set-AzAlertProcessingRule).
StudyCerts
StudyCerts