This chapter covers Azure Alerts and Action Groups, a critical part of the monitoring and alerting infrastructure in Azure. For the AZ-104 exam, this topic appears in the 'Monitor and Maintain Azure Resources' domain (objective 5.1) and typically accounts for 10-15% of exam questions. Understanding how to configure alert rules, define action groups, and integrate with other monitoring tools is essential for passing the exam and for real-world Azure administration.
Jump to a section
Azure Alerts and Action Groups work like a building's fire alarm system. The fire alarm (alert) monitors for smoke or heat (metrics/logs). When triggered, it sends a signal to a central panel (Azure Monitor). The panel then activates action groups, which are like the automated dispatch list: it calls the fire department (automated response like Azure Automation runbooks), pages the building manager (email/SMS to administrators), and turns on sprinklers (auto-scaling or VM shutdown). Each action group is a pre-configured set of actions: email, SMS, voice call, webhook, ITSM ticket, or runbook. The alert rule defines the condition—like a smoke detector sensitivity threshold—and how often to re-evaluate. Just as a fire alarm can be set to different sensitivity levels (heat rate vs. absolute temperature), Azure alerts can be based on metric thresholds, log search results, or activity log events. The system ensures the right people and automated processes respond appropriately to incidents, reducing downtime and manual oversight.
What Are Azure Alerts and Action Groups?
Azure Alerts proactively notify you when conditions are met in your monitoring data. They are the primary mechanism for detecting and responding to critical issues in your Azure resources. Action Groups define who and what gets notified or triggered when an alert fires. Together, they form the reactive part of Azure Monitor.
Why They Exist
Without alerts, you would need to manually check dashboards or logs continuously. Alerts enable automated detection of issues like high CPU, disk space, application errors, or security events. Action groups allow you to standardize responses—notify the on-call engineer, trigger an auto-scaling action, or create an IT service management (ITSM) ticket.
How It Works Internally
Azure Monitor collects metrics and logs from resources. An alert rule consists of: - Resource: The target Azure resource (VM, database, etc.). - Condition: A signal (metric or log) and logic (e.g., CPU > 90% for 5 minutes). - Actions: One or more action groups. - Alert details: Severity (0-4), description, etc.
When the condition is met, the alert fires. The alert state transitions from 'New' to 'Acknowledged' or 'Closed' manually or via automation. Action groups execute actions like sending email, SMS, voice call, webhook, Azure Automation runbook, Azure Function, ITSM connector, or logic app.
Key Components, Values, Defaults, and Timers
Alert Rules: - Signal Type: Metric, Log (Log Analytics), Activity Log. - Condition: For metrics, you set an operator (greater than, less than), threshold (e.g., 90), aggregation (average, total, etc.), and evaluation frequency (e.g., every 1 minute) with a window of (e.g., 5 minutes). - Severity: 0 (Critical) to 4 (Verbose). Exam expects you to know Sev 0 is highest. - Auto-resolve: For metric alerts, you can set auto-resolve after a period (e.g., 5 minutes).
Action Groups: - Action types: - Email/SMS/Push/Voice: Limit of 10 email actions, 10 SMS actions per action group. - Webhook: Must accept JSON payload; timeout is 10 seconds; retry once after 10 seconds. - Azure Automation Runbook: Queued; runs asynchronously. - Azure Function: Invoked with HTTP trigger. - ITSM Connector: Connects to ServiceNow, etc. - Logic App: Can be triggered. - Action Group limits: Up to 2,000 action groups per subscription. Each action group can have up to 10 actions of each type (except email and SMS have max 10 each). - Default SMS: 1 SMS per phone number per 5 minutes to prevent spamming.
Activity Log Alerts:
Monitor Azure resource changes (create, delete, update) or service health events.
Scope can be subscription or resource group.
Configuration and Verification Commands
You can create alert rules and action groups via Azure Portal, CLI, or PowerShell.
Azure CLI Example:
# Create action group
az monitor action-group create \
--resource-group myResourceGroup \
--name myActionGroup \
--short-name myAG \
--email-receiver name=admin email=admin@contoso.com use-common-alert-schema=true
# Create metric alert rule
az monitor metrics alert create \
--resource-group myResourceGroup \
--name "High CPU Alert" \
--description "Alert when CPU > 90%" \
--condition "percentage CPU > 90 avg 5m" \
--scopes /subscriptions/.../virtualMachines/myVM \
--action-groups /subscriptions/.../actionGroups/myActionGroupPowerShell Example:
New-AzActionGroup -ResourceGroupName myResourceGroup -Name myActionGroup -ShortName myAG -EmailReceiver -Name admin -EmailAddress admin@contoso.com
Add-AzMetricAlertRuleV2 -ResourceGroupName myResourceGroup -Name "High CPU Alert" -WindowSize 00:05:00 -Frequency 00:01:00 -TargetResourceId $vm.Id -Condition $condition -ActionGroupId $actionGroup.IdInteraction with Related Technologies
Azure Monitor: Alerts are a feature of Azure Monitor. They use metric data from Azure Monitor Metrics and log data from Log Analytics workspaces.
Azure Automation: Action groups can trigger runbooks for automated remediation (e.g., restart a VM).
Azure Functions: Can process alerts and perform custom logic.
ITSM Connector: Integrates with ServiceNow, System Center Service Manager, etc.
Webhooks: Can integrate with third-party tools like Slack, PagerDuty, or custom apps.
Exam-Relevant Details
Alert rules can be based on single or multiple conditions (for log alerts).
Metric alerts are stateful: they fire only when the condition is met and resolve when condition is no longer met (if auto-resolve is enabled).
Log alerts are stateless: they fire each time the query returns results (unless configured as 'number of results' threshold).
Activity log alerts are stateless: they fire each time an event matching the criteria occurs.
Action group can be reused across multiple alert rules.
Common Alert Schema: Standardizes the alert payload across all alert types. Recommended for webhooks and runbooks.
Alert processing rules: Allow you to modify alerts before they fire (suppress, apply action groups, etc.). Useful for maintenance windows.
Summary of Key Numbers
Max action groups per subscription: 2,000
Max actions per action group: 10 per type (email, SMS, etc.)
Max email receivers per action group: 10
Max SMS receivers per action group: 10
Webhook timeout: 10 seconds, retry once after 10 seconds
SMS rate limit: 1 SMS per phone number per 5 minutes
Alert rule evaluation frequency: as low as 1 minute (for metric alerts)
Metric alert window: up to 1 day (1440 minutes)
Log alert frequency: as low as 5 minutes (for log alerts)
Severity levels: 0 (Critical) to 4 (Verbose) – exam expects 0-4 range.
Define the Alert Condition
Identify the signal you want to monitor: a metric (e.g., CPU percentage), a log query (e.g., error events), or an activity log event (e.g., VM creation). For metrics, choose the resource, metric, aggregation (e.g., average), operator (greater than), threshold (e.g., 90), and evaluation window (e.g., 5 minutes). For logs, write a KQL query that returns results when the condition is true. For activity log, select the event category (Administrative, Service Health, etc.) and specific operation (e.g., Microsoft.Compute/virtualMachines/write).
Create an Action Group
If you don't have one already, create an action group that defines the response. Provide a name, short name (max 12 chars), and subscription/resource group. Add actions: email (up to 10), SMS (up to 10), voice call, webhook, Azure Automation runbook, Azure Function, ITSM connector, logic app, or secure webhook. For email/SMS, you can set a role (e.g., owner, contributor) to dynamically send to users with that role. Each action can have a name and must be configured with appropriate endpoints (email address, phone number, webhook URL).
Configure Alert Rule Details
Assign a severity level (0-4), alert rule name, description (optional), and associate the action group. You can also set auto-resolve for metric alerts (the alert will close automatically when condition is no longer met). For log alerts, you must specify the evaluation frequency (e.g., every 5 minutes) and the period over which to evaluate the query (e.g., last 15 minutes). Optionally, enable the common alert schema to standardize the payload.
Test the Alert Rule
Before deploying, test the alert by triggering the condition. For metric alerts, you can temporarily stress the resource (e.g., run a CPU-intensive task). For log alerts, ensure your query returns data. For activity log alerts, perform the monitored action (e.g., create a VM). Verify that the alert fires and the action group executes (e.g., you receive the email/SMS). Check the alert history in Azure Monitor > Alerts to see state transitions.
Manage and Maintain Alerts
Monitor alert rules for effectiveness. Use alert processing rules to suppress alerts during maintenance windows (e.g., every Sunday 2-4 AM). Set up action groups to trigger automated remediation (e.g., a runbook that restarts a VM). Review alert history and adjust thresholds to reduce noise. Use Azure Monitor Workbooks and dashboards to visualize alert trends. Periodically audit action groups to ensure contact information is current.
Enterprise Scenario 1: Production VM Monitoring
A large e-commerce company monitors its fleet of 500 production VMs. They create a metric alert rule for 'Percentage CPU > 90% for 5 minutes' on each VM. An action group sends an email to the operations team and triggers a webhook to their incident management system (PagerDuty). To avoid alert fatigue, they set auto-resolve after 10 minutes. They also create an alert processing rule to suppress alerts during their weekly maintenance window (Sunday 2-4 AM). The team finds that metric alerts are reliable for performance issues but need to adjust thresholds based on baseline data.
Enterprise Scenario 2: Security Incident Response
A financial institution monitors Azure Activity Log for suspicious operations like 'Microsoft.Compute/virtualMachines/write' from unexpected IPs. They create an activity log alert with a Log Analytics workspace query that correlates the event with user identity. The action group triggers an Azure Automation runbook that disables the VM's network interface and sends an SMS to the security team. They also use ITSM connector to create a ServiceNow incident. The challenge is ensuring the runbook has appropriate permissions (Managed Identity) and that the SMS is not rate-limited.
Enterprise Scenario 3: Multi-Tier Application Alerting
A SaaS provider monitors a multi-tier application: web servers, app servers, and databases. They use log alerts on Application Insights to detect HTTP 500 errors. The action group varies by severity: Critical errors trigger a voice call to the on-call engineer, while warnings send an email to the team. They also use a webhook to update a status dashboard. Performance consideration: log alerts can be expensive if queries scan large volumes of data; they optimize by using workspace-scoped alerts and setting appropriate frequency. Misconfiguration often leads to missed alerts when the query returns zero results but the condition is actually met (e.g., no data is an issue itself).
What AZ-104 Tests
AZ-104 objective 5.1: 'Configure and manage alerts and action groups'. The exam expects you to:
Create and configure alert rules for metrics, logs, and activity log.
Create and manage action groups.
Understand alert states (New, Acknowledged, Closed).
Differentiate between metric, log, and activity log alerts.
Know the limits (max 10 email/SMS per action group, 2000 action groups per subscription).
Understand common alert schema and when to use it.
Configure alert processing rules (suppression during maintenance).
Common Wrong Answers
'Action groups can only be used for one alert rule.' – Wrong. Action groups are reusable across many alert rules.
'Log alerts are stateful like metric alerts.' – Wrong. Log alerts are stateless; they fire every time the query returns results. Metric alerts can be stateful with auto-resolve.
'You can have unlimited email receivers in an action group.' – Wrong. Max 10 email receivers per action group.
'Alert severity is from 1 to 5.' – Wrong. It's 0 (Critical) to 4 (Verbose).
Exam Numbers and Terms
Severity: 0-4 (0 = Critical, 4 = Verbose)
Action group limits: 10 email, 10 SMS, 10 webhook per group
Action groups per subscription: 2,000
Webhook timeout: 10 seconds, retry once
SMS rate limit: 1 per 5 minutes per number
Common alert schema: standardizes payload
Alert processing rules: for suppression or modification
Metric alerts: stateful (if auto-resolve enabled)
Log alerts: stateless
Activity log alerts: stateless
Edge Cases
If a metric alert has auto-resolve disabled, it stays in 'Fired' state until manually acknowledged or closed.
For log alerts, if the query returns no results (e.g., due to data not being ingested), the alert does not fire; this can be a problem if you want to alert on absence of data.
Activity log alerts do not support conditions based on the 'Status' field (e.g., 'Failed' events only) directly; you must use a filter on the 'Status' property.
Eliminating Wrong Answers
If the question mentions 'reusable notification configuration', think action group.
If it mentions 'automated response like restart VM', think action group with runbook.
If it mentions 'suppress alerts during maintenance', think alert processing rule.
If it mentions 'standardized payload', think common alert schema.
Action groups are reusable across alert rules; max 2000 per subscription.
Max 10 email and 10 SMS receivers per action group.
Webhook timeout is 10 seconds, with one retry.
SMS rate limit: 1 SMS per phone number per 5 minutes.
Alert severity: 0 (Critical) to 4 (Verbose).
Metric alerts can be stateful with auto-resolve; log and activity log alerts are stateless.
Common alert schema standardizes the alert payload for all action types.
Alert processing rules allow suppression or modification of alerts (e.g., during maintenance).
Activity log alerts monitor Azure resource changes and service health events.
Log alerts require a Log Analytics workspace and can be expensive if queries are broad.
These come up on the exam all the time. Here's how to tell them apart.
Metric Alerts
Based on numeric metric values (e.g., CPU > 90%)
Stateful if auto-resolve enabled (fires once, resolves automatically)
Low latency (evaluation as frequent as 1 minute)
Supports multiple conditions (and/or logic)
Can be scoped to individual resources or resource groups
Log Alerts
Based on KQL query results over Log Analytics data
Stateless (fires every time query returns results)
Higher latency (minimum frequency 5 minutes)
Supports complex logic via KQL (e.g., joins, aggregations)
Can be scoped to workspace or multiple resources (resource-centric)
Mistake
Action groups can only be used for one alert rule.
Correct
Action groups are reusable across multiple alert rules. You can associate the same action group with hundreds of alert rules.
Mistake
Log alerts are stateful like metric alerts.
Correct
Log alerts are stateless. They fire every time the log query returns results. Metric alerts can be stateful if auto-resolve is enabled.
Mistake
You can have unlimited email receivers in an action group.
Correct
There is a limit of 10 email receivers per action group. Similarly, SMS is limited to 10 receivers.
Mistake
Alert severity ranges from 1 to 5.
Correct
Severity ranges from 0 (Critical) to 4 (Verbose). Sev 0 is the highest severity.
Mistake
Webhooks have a 30-second timeout.
Correct
Webhook timeout is 10 seconds, with one retry after another 10 seconds. Total 20 seconds max.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Metric alerts are based on numeric metrics (e.g., CPU percentage) and can be stateful (auto-resolve). They evaluate frequently (as low as 1 minute). Log alerts are based on KQL queries over Log Analytics data; they are stateless and fire every time the query returns results. Log alerts have a minimum frequency of 5 minutes and support complex logic.
Maximum 10 email receivers per action group. Similarly, SMS receivers are limited to 10. If you need more, consider using a distribution list or a different notification method like webhook.
Yes, action groups are designed to be reusable. You can associate the same action group with many alert rules. This centralizes notification configuration.
The common alert schema standardizes the JSON payload sent to action groups (webhooks, runbooks, etc.). It ensures a consistent structure regardless of alert type (metric, log, activity log). It is recommended for integrations.
Use alert processing rules. You can create a rule that suppresses alerts for a specific resource or resource group during a defined schedule (e.g., every Sunday 2-4 AM). This prevents unnecessary notifications.
Azure SMS alert notifications are limited to 1 SMS per phone number per 5 minutes. If multiple alerts fire within that window, only the first SMS is sent. This prevents spamming.
Yes, you can add an Azure Automation runbook as an action in an action group. The runbook must be published and can perform automated remediation, such as restarting a VM or scaling out.
You've just covered Azure Alerts and Action Groups — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?