Azure Monitor Alerts: Complete Setup Guide 2026

Azure Monitor alerts detect issues in your infrastructure, applications, and services before users notice them. Without proper alerting, a CPU spike, failing service, or slow API can degrade production for hours before anyone investigates. With Azure Monitor alerts configured correctly, the same issue triggers a notification within minutes, routes to the right team, and includes the exact resource and metric that crossed the threshold.

This guide walks through creating metric alerts, log search alerts, and activity log alerts in Azure Monitor. Each step includes the exact configuration needed, code examples where applicable, and troubleshooting guidance for the most common setup failures. By the end, you will know how to create alerts that fire reliably, route to the correct action groups, and avoid the noise that makes teams ignore alert channels entirely.

Prerequisites

Before creating Azure Monitor alerts, ensure you have the following:

• An active Azure subscription with resources to monitor (VMs, App Services, AKS clusters, or other Azure services)
• Azure RBAC permissions: Reader on the target resource, Contributor on the resource group where you create the alert rule
• Azure CLI installed (if creating alerts via command line instead of portal)
• Basic familiarity with the metrics or logs you want to alert on (CPU percentage, HTTP 5xx errors, log query results)
• An action group already created, or permissions to create one (action groups define who gets notified and how)

For production use, you should also have:

• A monitoring strategy document that defines what metrics matter, what thresholds trigger alerts, and who responds to each alert type
• Runbooks or playbooks that explain what to do when specific alerts fire
• A way to track alert noise over time so you can tune thresholds and reduce false positives

Step 1: Understand Azure Monitor Alert Types

Azure Monitor supports several alert types. Choosing the correct type depends on the signal you want to monitor.

Metric alerts evaluate resource metrics at regular intervals. Use these for infrastructure signals like CPU percentage, memory usage, disk IOPS, or application metrics like request rate and error count. Metric alerts support static thresholds (alert when CPU exceeds 80%) and dynamic thresholds (alert when CPU deviates from learned baseline behavior).

Log search alerts run a query against Log Analytics at a defined frequency and fire when the query result meets a condition. Use these for complex conditions that require filtering or aggregating log data, such as “alert when more than 10 failed login attempts from the same IP in 5 minutes” or “alert when application error rate exceeds 5% across all instances.”

Activity log alerts trigger when a specific event occurs in the Azure Activity Log. Use these to track control plane operations like “a VM was deleted” or “a network security group rule was modified.” Activity log alerts are not for monitoring application performance but for detecting unexpected changes to Azure resources.

Smart detection alerts in Application Insights automatically detect anomalies in web app performance. These are enabled by default when you create an Application Insights resource and do not require manual configuration.

For this guide, we focus on metric alerts and log search alerts, the two types most teams configure for production monitoring.

Step 2: Create a Metric Alert Rule

Metric alerts are the most common alert type. This example creates a metric alert that fires when CPU percentage on a virtual machine exceeds 80% for 5 minutes.

In the Azure portal, navigate to Monitor from the left menu, then select Alerts. Click + Create and choose Alert rule.

On the Scope tab, click Select resource. Filter by subscription, resource type, and location to find the VM you want to monitor. Select the VM and click Done.

On the Condition tab, click See all signals. In the signal list, search for “Percentage CPU” and select it. This opens the signal configuration pane.

Set the following values:

• Threshold: Static
• Operator: Greater than
• Aggregation type: Average
• Threshold value: 80
• Unit: Percent
• Check every: 1 minute
• Lookback period: 5 minutes

This configuration means: “Fire an alert if the average CPU percentage over the last 5 minutes exceeds 80%, and check this condition every 1 minute.”

Click Done to save the condition.

On the Actions tab, click Select action group. If you have an existing action group that sends emails or Slack messages, select it here. If not, click + Create action group to define who gets notified and how.

On the Details tab, set:

• Alert rule name: VM-CPU-High
• Description: Alert when VM CPU exceeds 80% for 5 minutes
• Severity: 2 – Warning
• Enable upon creation: Yes
• Resource group: The same resource group as the monitored VM

Click Review + create, then Create. The alert rule is now active. When the condition is met, Azure Monitor fires the alert and triggers the action group.

Step 3: Create a Log Search Alert Rule

Log search alerts run a KQL (Kusto Query Language) query against Log Analytics and fire when the result meets a condition. This example creates an alert that fires when more than 100 HTTP 5xx errors occur in a 10 minute window.

In the Azure portal, go to Monitor > Alerts > + Create > Alert rule.

On the Scope tab, select the Log Analytics workspace where your application logs are stored. If you are monitoring an App Service or AKS cluster, select the workspace connected to that resource.

On the Condition tab, click See all signals and search for “Custom log search”. Select it.

In the query editor, enter this KQL query:

requests
| where resultCode startswith "5"
| summarize Count = count() by bin(timestamp, 10m)
| where Count > 100

This query counts HTTP 5xx responses in 10 minute bins and returns rows where the count exceeds 100.

Set the following alert logic:

• Based on: Number of results
• Operator: Greater than
• Threshold value: 0
• Frequency of evaluation: 10 minutes
• Period: 10 minutes

This means: “Run the query every 10 minutes. If the query returns at least 1 row (meaning at least one 10 minute bin had more than 100 errors), fire the alert.”

On the Actions tab, select or create an action group that routes to your incident response channel.

On the Details tab, set:

• Alert rule name: HTTP-5xx-High
• Severity: 1 – Error
• Enable upon creation: Yes

Click Review + create, then Create.

Step 4: Configure Action Groups for Alert Routing

Action groups define what happens when an alert fires. Without an action group, Azure Monitor creates the alert instance but does not notify anyone.

To create an action group, go to Monitor > Action groups > + Create.

Set:

• Subscription: Your subscription
• Resource group: Same resource group as your alerts
• Action group name: ProdOps-Notify
• Display name: ProdOps

On the Notifications tab, add one or more notification methods:

• Email/SMS/Push/Voice: Enter email addresses or phone numbers
• Email Azure Resource Manager Role: Select a role like Contributor or Owner to email all users with that role

On the Actions tab, add optional automation:

• Webhook: Send alert payload to an external API
• Azure Function: Trigger a serverless function
• Logic App: Start a workflow
• Automation Runbook: Run a PowerShell or Python script

For most teams, email and Slack webhook notifications are sufficient. If you use Slack, create an incoming webhook in your Slack workspace, then add it as a webhook action here with the payload format set to common alert schema.

Click Review + create, then Create.

Step 5: Test the Alert Rule

After creating an alert rule, verify it fires correctly before relying on it in production.

For metric alerts, the easiest way to test is to generate load that crosses the threshold. For a CPU alert on a VM, SSH into the VM and run a stress test:

sudo apt-get install stress
stress --cpu 8 --timeout 600s

This command maxes out 8 CPU cores for 10 minutes. Within 5 minutes, the metric alert should fire. Check the Alerts page in Azure Monitor to see the fired alert instance.

For log search alerts, generate log entries that match the query condition. For the HTTP 5xx example, trigger 5xx errors in your application by calling a broken endpoint repeatedly, then wait for the next evaluation period (10 minutes in the example). The alert should fire and appear in the alerts list.

If the alert does not fire, check:

• The resource is sending the expected metric or log data to Azure Monitor
• The query returns results when run manually in Log Analytics
• The lookback period and frequency are configured correctly
• The action group is correctly attached to the alert rule

Step 6: Use Dynamic Thresholds for Metric Alerts

Static thresholds (CPU > 80%) work for predictable workloads. For resources with variable load patterns, dynamic thresholds use machine learning to calculate expected baselines and alert on deviations.

To create a metric alert with dynamic thresholds, follow the same steps as Step 2, but on the Condition tab, set:

• Threshold: Dynamic
• Operator: Greater than or Lower than (alerts on both upper and lower bound deviations)
• Threshold sensitivity: Medium (options: Low, Medium, High)

Dynamic thresholds analyze the metric’s historical behavior over the last few days and calculate upper and lower bounds. If the current value deviates significantly from the learned pattern, the alert fires.

This reduces false positives for workloads with daily or weekly traffic patterns. For example, an e-commerce site might see 10x traffic on weekends. A static CPU threshold would fire constantly on Saturdays. A dynamic threshold learns the weekend pattern and only fires if CPU exceeds the expected weekend baseline.

Step 7: Set Up Activity Log Alerts for Resource Changes

Activity log alerts fire when specific Azure operations occur. This example creates an alert that fires when a VM is deleted.

In the Azure portal, go to Monitor > Alerts > + Create > Alert rule.

On the Scope tab, select the subscription or resource group you want to monitor. Activity log alerts apply to all resources in the selected scope.

On the Condition tab, set:

• Signal name: Delete Virtual Machine (Microsoft.Compute/virtualMachines)
• Event level: All selected
• Status: All selected

On the Actions tab, select an action group that notifies your operations team.

On the Details tab, set:

• Alert rule name: VM-Deleted-Alert
• Severity: 0 – Critical

Click Review + create, then Create.

Now, any time a VM is deleted in the selected scope, the alert fires immediately. This is useful for detecting accidental deletions or unauthorized changes.

Step 8: Configure Alert Suppression and Grouping

Alert fatigue is real. If an alert fires every minute for the same issue, teams start ignoring the channel entirely. Azure Monitor provides two mechanisms to reduce noise: alert processing rules and smart grouping.

Alert processing rules let you suppress or modify alerts based on conditions. For example, suppress all alerts during a planned maintenance window, or add a tag to alerts from a specific resource group.

To create an alert processing rule, go to Monitor > Alert processing rules > + Create.

Set:

• Scope: Select the subscription or resource group
• Filter: Add filters like resource type, alert severity, or alert rule name
• Rule settings: Choose “Suppress notifications” or “Apply action group”
• Schedule: Always, or define a recurring schedule (e.g., every Saturday 2am-4am UTC)

Smart grouping automatically combines related alerts into a single notification. For example, if 10 VMs in the same availability set all fire CPU alerts at the same time, smart grouping creates one grouped alert instead of 10 individual notifications. This is enabled by default but can be configured per action group.

Troubleshooting Common Issues

Alert rule created but never fires

Check that the resource is emitting the metric or log data you are alerting on. In the Azure portal, go to the resource and view its metrics or logs directly. If the data is missing, the alert cannot evaluate.

For log search alerts, run the query manually in Log Analytics. If it returns no rows, the alert will never fire. Verify the query syntax and that the log source is configured correctly.

Alert fires but no notification is received

Verify the action group is correctly attached to the alert rule. Go to the alert rule, check the Actions tab, and confirm the action group is listed.

Check the action group itself. Go to Monitor > Action groups, select the group, and verify the email addresses or webhook URLs are correct.

Check your email spam folder. Azure Monitor emails sometimes get flagged by corporate email filters. Add [email protected] to your safe senders list.

Alert fires too frequently or never stops firing

This usually means the threshold or lookback period is misconfigured. For metric alerts, increase the lookback period or adjust the threshold. For log search alerts, check the query logic to ensure it is not returning results continuously.

If the underlying issue persists, the alert will continue firing until resolved. Use alert processing rules to suppress repeated notifications after the first one, or configure the action group to throttle notifications.

Dynamic threshold alerts fire unexpectedly

Dynamic thresholds learn from historical data. If a resource is new or its behavior changed recently, the baseline may not yet be accurate. Wait a few days for the model to stabilize, or switch to a static threshold during the stabilization period.

If the resource has genuinely unusual behavior (extreme spikes or drops), dynamic thresholds may fire correctly. Review the metric chart in the alert details to see the learned upper and lower bounds and whether the deviation was legitimate.

Log search alert query times out

Log Analytics queries have a 10 minute execution limit. If your query scans too much data or uses inefficient logic, it may time out and the alert will not evaluate.

Optimize the query by:

• Adding time filters at the top of the query (e.g., where timestamp > ago(10m))
• Using summarize instead of scanning every row
• Limiting the number of joined tables
• Reducing the lookback period

Alert rule shows “Degraded” or “Failed” state

This indicates Azure Monitor could not evaluate the alert rule. Common causes:

• The target resource was deleted
• The Log Analytics workspace was deleted or the query references a table that no longer exists
• Insufficient RBAC permissions on the resource or workspace
• The action group was deleted

Check the alert rule’s Alert rule condition tab in the portal for specific error messages.

Frequently Asked Questions

Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve. Features, pricing, and plan limits can change over time. Always verify the latest information directly with the vendor before making purchasing or deployment decisions.