Azure Monitor alerts notify you when collected metric or log data indicates a possible problem. A metric alert combines the resource to monitor, a signal, a condition, and optional action groups that notify people or start automation. [1]
Choose the alert before opening the portal
Start with a signal that a person can act on. Examples include high CPU on a virtual machine, low available capacity, elevated failed requests, or an application response-time threshold. Define the owner, response action, and acceptable threshold before creating the rule.
Metric alerts evaluate resource metrics. Log search alerts use Log Analytics queries, while activity log alerts react to control-plane events. This guide covers a metric alert.
1. Open alert creation from the resource
- Open the Azure resource you want to monitor.
- Select Alerts from the resource menu.
- Select + Create, then Alert rule.
- Confirm the alert scope is the intended resource.
You can also open Monitor > Alerts and create or manage alert rules centrally. To create a rule, you need read permission on the target resource and write permission on the resource group where the alert rule is created. [2]
2. Select the signal and condition
- On the Condition tab, select Signal name.
- Choose a commonly used metric or select See all signals to find another one.
- Choose the aggregation type, such as Average, Minimum, Maximum, Sum, or Count.
- Choose a static threshold or dynamic threshold.
- Set the operator, threshold value, unit, and evaluation frequency.
- Review the preview graph before continuing.
Dynamic thresholds use learned metric behavior patterns. They can be helpful when a fixed number would create noise because normal activity changes over time. A static threshold is easier to explain when the operational limit is known.
3. Decide how many failures should trigger it
Use the evaluation settings to choose how often Azure checks the condition and how far back it looks. If the signal is noisy, require multiple violations within an evaluation period instead of paging on one short-lived spike. For a critical capacity limit, a shorter check interval may be justified.
4. Add an action group
On the Actions tab, select an existing action group or create one. Action groups can send email, SMS, or push notifications and can also start automation such as Azure Functions, Logic Apps, runbooks, webhooks, or ITSM workflows. [1]
Keep action groups purposeful. A low-severity alert should not notify every administrator. Use an appropriate owner or operations channel and document what the recipient should do.
5. Name, enable, and create the rule
- Enter a descriptive alert rule name.
- Add a description that explains the signal, threshold, owner, and response.
- Choose whether to enable the rule upon creation.
- Enable automatic resolution when you want the metric alert to become stateful and resolve when the condition clears.
- Review the scope, condition, actions, and tags.
- Select Review + create, then Create.
Microsoft distinguishes fired alert state from user response. A user can acknowledge or close an alert, but the underlying condition and its resolution are separate concepts. [1]
6. Test the notification path
- Confirm the rule appears under Monitor > Alerts > Alert rules.
- Use a safe test condition or a non-production resource where possible.
- Verify that the action group sends the expected notification.
- Confirm the message identifies the resource, signal, threshold, and link to investigate.
- Resolve the test condition and confirm the resolved notification if automatic resolution is enabled.
Common mistakes
- Creating multiple rules for the same signal and generating duplicate notifications.
- Choosing a threshold without checking the metric’s normal range.
- Sending every alert to a broad distribution list.
- Forgetting to grant the creator write access to the alert rule’s resource group.
- Never testing whether the action group reaches the person who is expected to respond.
