Stage 5 · Platform
Azure Monitor & Observability
Alerting in Azure
Metric alerts, log query alerts, action groups, and PagerDuty integration.
Alerting Overview
Azure Monitor alerts notify you when important conditions are found in your monitoring data. They can trigger notifications, automation, or ITSM integration. Alert rules define what to monitor and action groups define what happens when an alert fires.
- Metric alerts — Triggered by metric thresholds (CPU > 80% for 5 minutes)
- Log query alerts — Triggered by KQL query results (errors > 100 in 5 minutes)
- Activity log alerts — Triggered by Azure operations (resource deletion, policy violation)
- Smart detection — ML-based anomaly detection in Application Insights
Metric Alerts
Metric alerts evaluate a condition against metric data at regular intervals. They support static thresholds (fixed value) and dynamic thresholds (ML-based anomaly detection).
# Create an action group first
az monitor action-group create \
--resource-group rg-monitoring \
--name ag-oncall \
--short-name oncall \
--action email admin admin@contoso.com
# Create a metric alert for high CPU
az monitor metrics alert create \
--resource-group rg-payments \
--name "High CPU - Payments VM" \
--scopes "/subscriptions/{sub-id}/resourceGroups/rg-payments/providers/Microsoft.Compute/vmScaleSets/vmss-web" \
--condition "avg Percentage CPU > 80" \
--window-size 5m \
--evaluation-frequency 1m \
--action "/subscriptions/{sub-id}/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-oncall" \
--description "Alert when CPU exceeds 80% for 5 minutes"The --condition format is 'aggregation metric operator threshold'. Aggregation can be avg, min, max, or total. Window-size defines the evaluation window.
Log Query Alerts
Log query alerts run a KQL query against a Log Analytics workspace and trigger when the result meets a threshold. They are more flexible than metric alerts because KQL can correlate multiple data sources.
# Alert when more than 100 errors occur in 5 minutes
az monitor scheduled-query create \
--resource-group rg-monitoring \
--name "Error Spike - Payments" \
--scopes "/subscriptions/{sub-id}/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-payments" \
--condition "count > 100" \
--query "AzureDiagnostics | where Level == 'Error' | where ResourceProvider == 'MICROSOFT.COMPUTE'" \
--window-size 5m \
--evaluation-frequency 1m \
--action "/subscriptions/{sub-id}/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-oncall"Log query alerts query the workspace every --evaluation-frequency and evaluate the query over the --window-size. The query must return a single scalar value.
Log alerts can query multiple tables and join results. This makes them ideal for alerting on complex conditions that span multiple data sources.
Action Groups
Action Groups define the notification and automation actions taken when an alert fires. They support email, SMS, push notifications, webhooks, and Azure Automation runbooks.
az monitor action-group create \
--resource-group rg-monitoring \
--name ag-critical \
--short-name critical \
--action email primary-oncall primary@contoso.com \
--action email secondary-oncall secondary@contoso.com \
--action sms primary-sms +15551234567 \
--action webhook pagerduty-webhook https://events.pagerduty.com/integration/xxx/enqueueAll actions in an action group fire simultaneously when triggered. Create separate action groups for different severity levels (warning, critical, etc.).
Alert Processing Rules
Alert Processing Rules override action group behavior based on conditions. Use them to suppress alerts during maintenance windows or route alerts to different teams based on resource tags.
# Suppress alerts during a maintenance window
az monitor alert-processing-rule create \
--resource-group rg-monitoring \
--name "maintenance-window-suppress" \
--scope "/subscriptions/{sub-id}/resourceGroups/rg-payments" \
--condition "targetResourceType = 'Microsoft.Compute/virtualMachineScaleSets'" \
--action-type SuppressionAction \
--suppression-duration 2025-01-20T02:00:00Z/2025-01-20T06:00:00ZAlert Processing Rules apply at the subscription or resource group level. They filter by resource type, tags, or alert name to selectively modify alert behavior.
PagerDuty and External Integration
Azure Monitor integrates with external incident management platforms through webhooks. PagerDuty, OpsGenie, and ServiceNow can receive alerts directly from action groups.
# Create an action group with PagerDuty webhook
az monitor action-group create \
--resource-group rg-monitoring \
--name ag-pagerduty \
--short-name pd \
--action webhook pagerduty-incident \
"https://events.pagerduty.com/integration/your-integration-key/enqueue" \
--from-body '{"routing_key":"your-routing-key","event_action":"trigger","payload":{"summary":"{{alertContext.name}}","severity":"critical","source":"Azure Monitor"}}'The webhook body template uses mustache syntax to inject alert context. PagerDuty receives the webhook and creates an incident based on the payload.
Too many alerts cause teams to ignore all alerts. Start with a small number of critical alerts, tune thresholds based on real data, and gradually expand coverage.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.