alert rule
What it is
An Azure Monitor alert rule evaluates a signal against a condition. When the condition is met, it creates an alert and can trigger an action group. The signal might be a metric, log query, activity-log event, or availability-test result.
Think of a smoke detector’s rule: “if smoke remains above this level, sound the alarm.” The rule is not the smoke sensor and not the fire brigade’s phone number; it connects the evidence to a defined response.
Why it exists
Teams cannot watch every chart all day. An alert rule makes an operational threshold explicit and records when a signal crosses it, so people or automation can investigate promptly.
Key ideas
- The signal is the data to evaluate: for example, failed requests, CPU use, a log-query result, or an availability test failure.
- The condition defines the threshold, aggregation, and evaluation frequency. A good condition reflects an actionable problem, not merely an interesting number.
- The action group specifies notifications or automated actions, such as email, SMS, webhook, or an automation runbook. The rule can exist without the response being useful to the right team.
- A rule has a severity and state. State-aware alerting can notify when a problem begins and when it resolves instead of sending the same notification every evaluation period.
- Test and tune rules using real signals, then review noisy, missing, and obsolete alerts. Alerting is a feedback loop, not a one-time configuration task.
Northwind example
Northwind’s availability test reports the public checkout page from five locations. Maya’s alert rule opens a high-severity alert when the configured number of locations fail. Its action group sends the alert to the operations channel and calls the incident webhook. When the page recovers, the rule records resolution so the team can close or investigate the incident with the test and server telemetry.
Alert rule versus action group
| Component | Main job |
|---|---|
| Alert rule | Decide whether observed data meets a problem condition. |
| [[action-group | Action group]] |
| [[availability-test | Availability test]] |
Common confusion
- An alert is not a diagnosis. It says a condition occurred; responders still need telemetry and context to find the cause.
- A low threshold can create alert fatigue, while a high threshold can hide real customer impact. Tune it against service objectives and evidence.
- An alert rule does not fix a problem unless its action group deliberately invokes safe automation.
Related
azure-monitor · application-insights · availability-test · action-group · northwind-traders-case-study
Sources and re-audit
- Microsoft Learn — Overview of Azure Monitor alerts, checked 2026-09-16.