Deploy Service Health alerts at scale using Azure Policy

This article explains how to deploy Service Health alerts across subscriptions using Azure Policy.

Requirements

See the permissions and roles required to run Azure Policy in Role-Based Access Control (RBAC) Azure RBAC permissions in Azure Policy.

Steps to deploy Service Health alert rules using Azure Policy in Azure portal

Service Health Alert rules can be deployed on a single subscription, or across all subscriptions in a management group by running the Configure subscriptions to enable Service Health Monitoring Alert Rules built-in policy.

1. From the Azure portal, navigate to Home > Policy.

2. Under Authoring > Assignments, check if Configure subscriptions to enable Service Health Monitoring Alert Rules is assigned.

3. If not already assigned, under Authoring > Definitions, search for Configure subscriptions to enable Service Health Monitoring Alert Rules and select it, or use this link

4. Select Assign policy.

5. In the Basics tab:

   

   • Set the Scope to the management group that contains the subscriptions you want the service health alerts deployed to. You can also choose to scope it to a single subscription. This policy doesn't support a resource group-level scope.
   • Under Exclusions, add any subscriptions that the policy shouldn’t update. These subscriptions aren't checked for compliance and don't have any alert rules or resources created through the policy.
   • Don't use any resource selectors.
   • Make sure the Policy Definition contains Configure subscriptions to enable Service Health Monitoring Alert rules. You can also update the assignment name and description if needed.

6. In the Parameters tab:

   • You can set the optional customization options (see Default Behavior and Customization Options).

7. In the Remediation tab:

   

   • Ensure the system assigned managed identity is selected, or assign a user assigned managed identity.
   • Select Create a remediation task to automatically apply the policy to existing subscriptions. Without this step, the policy only applies to new subscriptions.

8. Select Review and save the assignment.

Default behavior

When remediation runs, the policy automatically creates the following resources in all subscriptions that aren’t compliant:

• A resource group named rg-serviceHealthAlert.
• An enabled alert rule named ServiceHealthSubscriptionAlertRule.
• An action group named ag-ServiceHealthAlertActionGroup.

By default, the alert rules and action groups are configured to email subscription owners for all types service health events.

Customization options

• Effect: Allows the user to set the mode of the policy.
  

  • Disabled: The policy doesn't run.
    
  • AuditIfNotExists: The policy reports compliance but doesn't create any resources. It checks for the existence of an alert rule that has:
    
    • The appropriate state is (enabled/disabled).
      
    • A mapping to the action group is specified.
      
    • A condition that checks for the event types is specified.
      
  • DeployIfNotExists: During remediation, if the subscription is found to be noncompliant, it creates or updates the resources.

• Alert rule enabled:
  The state of the alert rule (enabled or disabled) created by this policy can be updated to enable or disable alert rules across subscriptions.

• Alert rule name:
  The name of the alert rule the policy creates. The policy doesn’t check the rule’s name, it only looks at the alert conditions, state, and whether it links to an action group.
  If a rule already exists that meets these requirements, the policy doesn't create a new one, even if the name is different. Changing the name doesn't remove any existing alert rules.

• Alert rule event types:
  The Service Health Event Types the alert rule checks for. This alert rule can be used to update the alerting condition across subscriptions.

• Existing action group resource ids:
  Enter the resource IDs of existing action groups within the management group or subscription (based on the policy’s scope) that should be used to send alerts. This action group can be used to alert across subscriptions.
  For more information, see Action Groups.

  

• New action group creation:
  

  • If set to true, the policy creates a new action group for alerts.
    
  • If set to false, no new action group is created. This step creates an action group in each subscription.
    It can be used along side the Existing action group resource ids parameter. Both are mapped to the alert rule.

• New action group name:
  Enter an action group name to create new action group. Updating the name doesn't delete any previously created action group. The alert rule mapping to the action group is updated.

• New action group roles to email:
  Arm built-in roles to notify using the new action group.
  The policy only checks if the alert rule is linked to the action groups, it doesn’t use this parameter to check compliance. If you change this setting after assigning the policy, it won’t update the action group.
  To apply updates across subscriptions, change the Alert rule enabled or Alert rule event types parameters, or set a new action group using the New action group name parameter.
  Possible values include:

  • Contributor
  • Owner
  • Reader
  • Monitoring Reader
  • Monitoring Contributor

• New action group resources:
  Resources to be used by the new action group to send alerts.
  Any specified resources must already exist.
  Currently email, logic app, Event Hubs, webhook, and Azure function are supported resources.
  Refer to documentation for Action Groups and integrations Logic App, or Send alerts with Webhook.
  The policy only checks if the alert rule is linked to the action groups as it doesn’t use this parameter to check compliance. If you change this setting after assigning the policy, it won’t update the action group.
  To apply updates across subscriptions, change the Alert rule enabled or Alert rule event types settings, or set a new action group using the New action group name option.

  

• Resource group name:
  This resource group name is used only if the policy needs to create an alert rule or action group.
  The policy doesn’t check the resource group name, it only checks the alert rule’s conditions, state, and if it links to an action group.
  If a matching rule exists in a different resource group, the policy doesn't create a new one. Changing the name doesn't delete any existing resource group, alert rule, or action group.

• Resource group location:
  The location used to create the resource group.

• Resource tags:
  Tags on the resources created by this policy.

Steps to deploy Service Health alert rules using Azure Monitor Baseline Alerts for Azure Landing Zone (AMBA-ALZ)

AMBA-ALZ offers advanced deployment scenarios like Bicep, Terraform, Azure Pipelines, GitHub Actions, and a broader range of coverage including platform alerts.

For references on how to deploy AMBA-ALZ, refer to Introduction to deploying the AMBA-ALZ Pattern.

For details about how to deploy Service Health alerts only, refer to Deploy only Service Health Alerts.