Alert Rules and Action Groups

Azure Basics · Azure Monitor – Metrics, Logs, Alerts, Log Analytics, Network Watcher · Lesson 3 of 5

An alert rule has a scope, a condition on a signal, a severity from 0 (most severe) to 4 and an action group; an action group bundles notifications and automated actions and is reused across rules.

An alert fires when monitoring data shows a problem. One unified alert experience covers every signal: metrics, logs, the Activity Log.

Part	Meaning	Example
Scope	The monitored resource	VM `vm-web`
Condition	Signal + logic + threshold	`avg Percentage CPU > 80` over a 5-minute window, evaluated every minute
Severity	Sev0 (Critical) → Sev4 (Verbose)	Sev2 (CLI default)
Action group	Who is told, what runs automatically	Email, SMS, push, voice, webhook, Automation runbook, Function, Logic App, ITSM

flowchart LR
  S["Signal: Percentage CPU"] --> C{"avg > 80<br/>window 5m, every 1m"}
  C -- "true" --> F["Alert Fired (Sev2)"]
  F --> AG["Action group ag-ops"]
  AG --> E["Email ops@example.com"]
  AG --> W["Webhook / runbook"]
  C -- "no longer breached" --> R["Resolved"]

States: the system sets the condition to Fired/Resolved; responders move it New → Acknowledged → Closed.
An action group is its own resource, reused by many rules. A rule with no action group still shows alerts in the Portal but sends no notifications.
--short-name (up to 12 characters) appears in SMS/email.
Classic alerts are retired; use the new metric/log alerts.

Traps: Sev0 is the most severe, not Sev4; a very short window makes alerts flap; forgetting the recovery path.

Command	Meaning
`az monitor action-group create -g rg-devops-lab -n ag-ops --short-name ops --action email ops ops@example.com`	Create an action group
`az monitor metrics alert create -g rg-devops-lab -n cpu-high --scopes "$VM_ID" --condition "avg Percentage CPU > 80" --action ag-ops`	Create a metric alert

Types of alert rules

Rule type	Signal	Example
Metric alert	Platform or custom metric	CPU above 80% for 5 minutes
Log search alert	KQL query result	More than 10 `500` errors in 15 minutes
Activity log alert	Control-plane event	A VM was deleted
Service Health alert	Azure incidents	An outage affects Southeast Asia
Prometheus alert	PromQL on managed Prometheus	Pod restarts in AKS
Smart detection	Application Insights anomalies	Sudden rise in failure rate

Smarter conditions

Dynamic thresholds learn a metric's normal pattern, including daily cycles, and alert on deviation instead of a fixed number.
Dimensions split one rule per instance, disk, or status code, so one rule watches every VM in a scale set separately.
Metric alerts are stateful by default: they fire once and resolve when the condition clears, instead of notifying every minute.

Quiet periods and routing

Alert processing rules act on fired alerts without editing the rules themselves: suppress notifications during a maintenance window, or add an action group to every Sev0 and Sev1 alert in a subscription. The common alert schema gives every notification the same JSON layout, so one webhook or Logic App can handle all of them.

Avoiding alert fatigue

Alert on symptoms that affect users (errors, latency, availability) rather than every internal metric. Give each alert a clear owner and a runbook link in its description, review alerts that fire often without action, and delete or tune them. A small number of trusted alerts beats a flood that people learn to ignore.

Testing

az monitor action-group test-notifications create sends a sample notification through an action group, so you can confirm that email, SMS, or a webhook really arrives before an incident.