Create a new alert rule

This article shows you how to create an alert rule. Learn more about alerts here.

You create an alert rule by combining:

  • The resource(s) to be monitored.
  • The signal or telemetry from the resource
  • Conditions

And then defining these elements for the resulting alert actions using:

Create a new alert rule in the Azure portal

  1. In the portal, select Monitor, then Alerts.

  2. Expand the + Create menu, and select Alert rule.

    Screenshot showing steps to create new alert rule.

  3. In the Select a resource pane, set the scope for your alert rule. You can filter by subscription, resource type, resource location, or do a search.

    You can see the Available signal types for your selected resource(s) at the bottom right of the pane. The available signal types change based on the selected resource.

    Screenshot showing the select resource pane for creating new alert rule.

  4. Select Include all future resources to include any future resources added to the selected scope.

  5. Select Done.

  6. Select Next: Condition> at the bottom of the page.

  7. In the Select a signal pane, the Signal type, Monitor service, and Signal name fields are pre-populated with the available values for your selected scope. You can narrow the signal list using these fields. The Signal type determines which type of alert rule you're creating.

  8. Select the Signal name, and follow the steps below depending on the type of alert you're creating.

    1. In the Configure signal logic pane, you can preview the results of the selected metric signal. Select values for the following fields.

      Field Description
      Select time series Select the time series to include in the results.
      Chart period Select the time span to include in the results. Can be from the last 6 hours to the last week.
    2. (Optional) Depending on the signal type, you may see the Split by dimensions section.

      Dimensions are name-value pairs that contain more data about the metric value. Using dimensions allows you to filter the metrics and monitor specific time-series, instead of monitoring the aggregate of all the dimensional values. Dimensions can be either number or string columns.

      If you select more than one dimension value, each time series that results from the combination will trigger its own alert, and will be charged separately. For example, the transactions metric of a storage account can have an API name dimension that contains the name of the API called by each transaction (for example, GetBlob, DeleteBlob, PutPage). You can choose to have an alert fired when there's a high number of transactions in a specific API (the aggregated data), or you can use dimensions to alert only when the number of transactions is high for specific APIs.

      Field Description
      Dimension name Dimensions can be either number or string columns. Dimensions are used to monitor specific time series and provide context to a fired alert.
      Splitting on the Azure Resource ID column makes the specified resource into the alert target. If detected, the ResourceID column is selected automatically and changes the context of the fired alert to the record's resource.
      Operator The operator used on the dimension name and value.
      Dimension values The dimension values are based on data from the last 48 hours. Select Add custom value to add custom dimension values.
      Include all future values Select this field to include any future values added to the selected dimension.
    3. In the Alert logic section:

      Field Description
      Threshold Select if threshold should be evaluated based on a static value or a dynamic value.
      A static threshold evaluates the rule using the threshold value that you configure.
      Dynamic Thresholds use machine learning algorithms to continuously learn the metric behavior patterns and calculate the appropriate thresholds for unexpected behavior. You can learn more about using dynamic thresholds for metric alerts.
      Operator Select the operator for comparing the metric value against the threshold.
      Aggregation type Select the aggregation function to apply on the data points: Sum, Count, Average, Min, or Max.
      Threshold value If you selected a static threshold, enter the threshold value for the condition logic.
      Unit If the selected metric signal supports different units,such as bytes, KB, MB, and GB, and if you selected a static threshold, enter the unit for the condition logic.
      Threshold sensitivity If you selected a dynamic threshold, enter the sensitivity level. The sensitivity level affects the amount of deviation from the metric series pattern is required to trigger an alert.
      Aggregation granularity Select the interval over which data points are grouped using the aggregation type function.
      Frequency of evaluation Select the frequency on how often the alert rule should be run. Selecting frequency smaller than granularity of data points grouping will result in sliding window evaluation.
    4. Select Done.

    From this point on, you can select the Review + create button at any time.

  9. In the Actions tab, select or create the required action groups.

    Screenshot of the actions tab when creating a new alert rule.

  10. In the Details tab, define the Project details by selecting the Subscription and Resource group.

  11. Define the Alert rule details.

    1. Select the Severity.

    2. Enter values for the Alert rule name and the Alert rule description.

    3. Select the Region.

    4. (Optional) In the Advanced options section, you can set several options.

      Field Description
      Enable upon creation Select for the alert rule to start running as soon as you're done creating it.
      Automatically resolve alerts (preview) Select to resolve the alert when the condition isn't met anymore.
    5. (Optional) If you have configured action groups for this alert rule, you can add custom properties to the alert payload to add additional information to the payload. In the Custom properties section, add the property Name and Value for the custom property you want included in the payload.

      Screenshot of the details tab when creating a new alert rule.

  12. In the Tags tab, set any required tags on the alert rule resource.

    Screenshot of the Tags tab when creating a new alert rule.

  13. In the Review + create tab, a validation will run and inform you of any issues.

  14. When validation passes and you've reviewed the settings, select the Create button.

    Screenshot of the Review and create tab when creating a new alert rule.

Create a new alert rule using CLI

You can create a new alert rule using the Azure CLI. The code examples below are using Azure Cloud Shell. You can see the full list of the Azure CLI commands for Azure Monitor.

  1. In the portal, select Cloud Shell, and at the prompt, use the following commands:

    To create a metric alert rule, use the az monitor metrics alert create command. You can see detailed documentation on the metric alert rule create command in the az monitor metrics alert create section of the CLI reference documentation for metric alerts.

    To create a metric alert rule that monitors if average Percentage CPU on a VM is greater than 90:

     az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes {VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description {descriptionofthealert}

Create a new alert rule using PowerShell

Create an activity log alert rule from the Activity log pane

You can also create an activity log alert on future events similar to an activity log event that already occurred.

  1. In the portal, go to the activity log pane.

  2. Filter or find the desired event, and then create an alert by selecting Add activity log alert.

    Screenshot of creating an alert rule from an activity log event.

  3. The Create alert rule wizard opens, with the scope and condition already provided according to the previously selected activity log event. If necessary, you can edit and modify the scope and condition at this stage. By default, the exact scope and condition for the new rule are copied from the original event attributes. For example, the exact resource on which the event occurred, and the specific user or service name who initiated the event, are both included by default in the new alert rule. If you want to make the alert rule more general, modify the scope, and condition accordingly (see steps 3-9 in the section "Create an alert rule from the Azure Monitor alerts pane").

  4. Follow the rest of the steps from Create a new alert rule in the Azure portal.

Create an activity log alert rule using an Azure Resource Manager template

To create an activity log alert rule using an Azure Resource Manager template, create a microsoft.insights/activityLogAlerts resource, and fill in all related properties.


The highest level that activity log alerts can be defined is the subscription level. Define the alert to alert per subscription. You can't define an alert on two subscriptions.

The following fields are the options in the Azure Resource Manager template for the conditions fields. (The Resource Health, Advisor and Service Health fields have extra properties fields.)

Field Description
resourceId The resource ID of the impacted resource in the activity log event on which the alert is generated.
category The category of the activity log event. Possible values: Administrative, ServiceHealth, ResourceHealth, Autoscale, Security, Recommendation, or Policy
caller The email address or Azure Active Directory identifier of the user who performed the operation of the activity log event.
level Level of the activity in the activity log event for the alert. Possible values: Critical, Error, Warning, Informational, or Verbose.
operationName The name of the operation in the activity log event. Possible values: Microsoft.Resources/deployments/write.
resourceGroup Name of the resource group for the impacted resource in the activity log event.
resourceProvider For more information, see Azure resource providers and types. For a list that maps resource providers to Azure services, see Resource providers for Azure services.
status String describing the status of the operation in the activity event. Possible values: Started, In Progress, Succeeded, Failed, Active, or Resolved
subStatus Usually, this field is the HTTP status code of the corresponding REST call. This field can also include other strings describing a substatus. Examples of HTTP status codes include OK (HTTP Status Code: 200), No Content (HTTP Status Code: 204), and Service Unavailable (HTTP Status Code: 503), among many others.
resourceType The type of the resource that was affected by the event. For example: Microsoft.Resources/deployments.

This example sets the condition to the Administrative category:

"condition": {
          "allOf": [
              "field": "category",
              "equals": "Administrative"
              "field": "resourceType",
              "equals": "Microsoft.Resources/deployments"

This is an example template that creates an activity log alert rule using the Administrative condition:

  "$schema": "",
  "contentVersion": "",
  "parameters": {
    "activityLogAlertName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Activity log alert."
    "activityLogAlertEnabled": {
      "type": "bool",
      "defaultValue": true,
      "metadata": {
        "description": "Indicates whether or not the alert is enabled."
    "actionGroupResourceId": {
      "type": "string",
      "metadata": {
        "description": "Resource Id for the Action group."
  "resources": [   
      "type": "Microsoft.Insights/activityLogAlerts",
      "apiVersion": "2017-04-01",
      "name": "[parameters('activityLogAlertName')]",      
      "location": "Global",
      "properties": {
        "enabled": "[parameters('activityLogAlertEnabled')]",
        "scopes": [
        "condition": {
          "allOf": [
              "field": "category",
              "equals": "Administrative"
              "field": "operationName",
              "equals": "Microsoft.Resources/deployments/write"
              "field": "resourceType",
              "equals": "Microsoft.Resources/deployments"
        "actions": {
              "actionGroupId": "[parameters('actionGroupResourceId')]"

This sample JSON can be saved as, for example, sampleActivityLogAlert.json. You can deploy the sample by using Azure Resource Manager in the Azure portal.

For more information about the activity log fields, see Azure activity log event schema.


It might take up to 5 minutes for the new activity log alert rule to become active.

Create a new activity log alert rule using the REST API

The Azure Monitor Activity Log Alerts API is a REST API. It's fully compatible with the Azure Resource Manager REST API. You can use it with PowerShell, by using the Resource Manager cmdlet or the Azure CLI.


This article uses the Azure Az PowerShell module, which is the recommended PowerShell module for interacting with Azure. To get started with the Az PowerShell module, see Install Azure PowerShell. To learn how to migrate to the Az PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

Deploy the Resource Manager template with PowerShell

To use PowerShell to deploy the sample Resource Manager template shown in the previous section section, use the following command:

New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile sampleActivityLogAlert.json -TemplateParameterFile sampleActivityLogAlert.parameters.json

The sampleActivityLogAlert.parameters.json file contains the values provided for the parameters needed for alert rule creation.

Changes to log alert rule creation experience

If you're creating a new log alert rule, note that current alert rule wizard is a little different from the earlier experience:

  • Previously, search results were included in the payload of the triggered alert and its associated notifications. The email included only 10 rows from the unfiltered results while the webhook payload contained 1000 unfiltered results. To get detailed context information about the alert so that you can decide on the appropriate action:
    • We recommend using Dimensions. Dimensions provide the column value that fired the alert, giving you context for why the alert fired and how to fix the issue.
    • When you need to investigate in the logs, use the link in the alert to the search results in Logs.
    • If you need the raw search results or for any other advanced customizations, use Logic Apps.
  • The new alert rule wizard doesn't support customization of the JSON payload.
    • Use custom properties in the new API to add static parameters and associated values to the webhook actions triggered by the alert.
    • For more advanced customizations, use Logic Apps.
  • The new alert rule wizard doesn't support customization of the email subject.
    • Customers often use the custom email subject to indicate the resource on which the alert fired, instead of using the Log Analytics workspace. Use the new API to trigger an alert of the desired resource using the resource ID column.
    • For more advanced customizations, use Logic Apps.

Next steps