A production service starts returning errors during a scheduled maintenance window. Azure Monitor detects the condition, an alert appears in the portal, and the on-call engineer receives no notification. That can be the intended result of a temporary suppression rule—or evidence that alert routing was configured incorrectly. The difference matters because an alert’s detection logic, its notification actions, and the policies that modify those actions are separate parts of Azure Monitor.
Administrators need a model that follows an alert from the signal that triggers it, through the fired alert record, to the people and systems that should respond. Alert rules decide when a problem is detected. Action groups define who or what receives a notification. Alert processing rules modify the action groups applied to fired alerts at a selected scope and time. A reliable configuration separates those jobs instead of treating one alert screen as the whole incident-response workflow.
Distinguish alert rules from the actions they trigger
Microsoft’s AZ-104 exam tests setting up alert rules, action groups, and alert processing rules under monitoring and maintenance. The distinction is useful beyond an exam scenario: a rule can fire correctly while email delivery, a webhook, or an automation action fails. Conversely, a notification may be delivered for an alert whose metric threshold or log query does not represent a real service problem.
| Component | Main responsibility | Question to ask during a failure |
|---|---|---|
| Alert rule | Evaluate a signal or event and create a fired alert | Was the rule enabled, was the condition met, and did the alert actually fire? |
| Action group | Notify recipients or start a supported workflow | Which email, mobile, webhook, Logic App, Function, or other action was selected? |
| Alert processing rule | Add action groups or suppress actions on fired alerts under a scope, filter, and schedule | Did another rule alter notification behavior for this alert? |
| Incident response process | Interpret the alert, assign ownership, and verify recovery | Did anyone act on the signal and confirm the application is healthy? |
The underlying signal belongs to the monitored service. For example, CPU percentage is a resource metric, whereas a Log Analytics query may count application failures over a chosen time window. Both can produce alerts, but their evaluation windows, dimensions, state, and cost implications differ. The broader Azure Monitor troubleshooting process should determine whether the signal is trustworthy before the team redesigns the notification path around it.
Build an action group for the job that must happen
An action group is a reusable collection of notification preferences and actions. It can send email, SMS or voice notifications where supported, invoke a webhook or secure webhook, call an Azure Function, or start a Logic Apps workflow. Supported action types and their costs or restrictions should be checked for the target Azure environment rather than assumed from a generic tutorial.
A single action group may be associated with several alert rules so the organization can maintain its recipient list or automation integration in one place. Microsoft currently allows up to five action groups directly on an alert rule, and the action group actions execute concurrently rather than in a guaranteed order. If one action must finish before another, orchestrate those dependent steps inside a workflow, not by assuming action-group delivery sequence.
Separate action groups by operational responsibility when doing so improves maintenance. A database availability incident may require the database on-call team, while a subscription-wide service-health issue may involve the platform operations team. Reusing a team-owned notification group can be safer than embedding individual engineers’ email addresses in dozens of alert rules. Ownership, rotation, escalation and the right to modify a group should be documented.
Use a predictable alert payload for automation
Email recipients can often understand a provider-generated subject and body, but automation usually needs stable machine-readable fields. Azure Monitor offers a common alert schema for supported notification actions. Enable it on the specific action or integration that will consume it, and verify the expected payload before building a parser around it. Microsoft documents that common schema opt-in applies at the action level.
A webhook endpoint must accept the supported HTTP POST, handle the actual alert payload, and have a clear authentication design. The secure webhook option uses Microsoft Entra ID for protected API endpoints rather than relying on a bare URL with embedded credentials. Logic Apps can be used to transform an alert payload and route it to another service when its expected schema differs from Azure Monitor’s original message.
A notification endpoint can fail even when the Azure Monitor alert is valid. Retried webhook delivery, rate limits, misconfigured keys, authentication failures and inaccessible endpoints are separate failure modes. Use a controlled action-group test where supported, monitor failures, and document which team owns the destination. Never treat a successful test email to one user as proof that the real production automation path works.
Alert processing rules operate after an alert fires
Alert processing rules were formerly called action rules; their underlying Azure resource type still reflects that history. They operate on fired alerts and can either apply additional action groups or suppress notifications. The alert rule still evaluates its own signal. This is why an engineer can see a fired alert in the portal even when an alert processing rule has suppressed its notifications.
A suppression rule removes all action groups from affected fired alerts. It does not merely delay notifications until maintenance ends. Suppressed alerts remain visible in the Azure portal, API and other supported alert views, but their suppressed action groups are not invoked retroactively after the window. If an incident must still create a ticket or reach an emergency operator, the suppression scope needs to be designed narrowly enough not to silence that workflow inadvertently.
Microsoft specifies that suppression takes priority over action-group application when both types of alert processing rule match the same fired alert. Creating another add-action-group rule does not override an active suppression rule. This precedence is a common reason a seemingly correct routing change has no visible effect.
Scope the rule to exactly the alerts being managed
Alert processing rules can operate on selected resources, resource groups, or a subscription, with optional filters on properties of the fired alert. Their applicable resources must be in the same subscription as the alert processing rule. A broad subscription-level rule can be useful for a consistent severity-based routing policy, but it can also suppress alerts for a system that is not part of the maintenance work.
Start with the smallest scope that meets the requirement. If one virtual machine is under maintenance, target that resource or a defensible group rather than every alert in the subscription. If a set of services belongs to the same operations team, describe how the rule filters the actual fired alerts rather than hoping the displayed resource-group name alone is an adequate incident ownership model.
When filters depend on alert details such as severity, monitoring service, target type or a text field, test them against actual fired alerts. An apparently simple filter may behave differently because of how a monitoring service formats or populates that field. A rule that matches no alerts is as operationally dangerous as one that matches too many when teams rely on it for routing.
Use maintenance schedules instead of disabling detection
Disabling an alert rule during maintenance stops the rule from generating new alerts while disabled. That can hide a genuine failure on another resource covered by the same alert rule. A scheduled alert processing rule gives teams a way to suppress notifications for selected fired alerts while continuing to record the underlying alert events.
Rules are active continuously by default unless configured otherwise. Azure Monitor supports one-time time windows and recurring schedules, so a team can express a planned outage or routine maintenance period. Capture the chosen time zone, start and end times, scope, alert filters and owner in the maintenance change record. Check overlaps with any recurring organization-wide routing rules.
Microsoft warns that creating or updating an alert processing rule may take up to 30 minutes to affect newly fired alerts. A maintenance change made at the exact start of the window can therefore leave a gap. Plan ahead and verify the effective behavior with a controlled event; do not use a saved configuration screen as your only evidence.
Design a realistic service maintenance scenario
Consider three applications in one Azure subscription. Only the API servers in the payments resource group are scheduled for a rolling deployment. A CPU alert rule covers multiple resources, and an existing action group pages the platform team. The operations lead wants to suppress routine CPU notifications from the maintenance scope for one hour without muting unrelated database alerts in the same subscription.
- Document the protected alerts. Identify the monitored resource IDs, severity, signal types and the action group that currently receives the notifications.
- Choose the narrow scope. Target the affected API resources or another well-defined maintenance scope rather than the entire subscription.
- Configure suppression as an alert processing rule. Add filters only when they reliably identify the intended fired alerts, then set the correct one-time maintenance schedule.
- Confirm the propagation boundary. Create the rule early enough for its configuration to become effective and record who will verify that it is active.
- Validate both sides. Trigger or observe a safe test alert for a targeted resource and a separate non-targeted resource. The targeted alert should still fire but not dispatch suppressed actions; the unrelated alert should retain its expected notification path.
- Close out maintenance. Confirm the suppression window ended, restore normal notification delivery, review any alerts that fired during maintenance, and verify actual application health.
This is a source-informed test plan, not a claim that a live Azure subscription test has been performed. Administrators should adapt it to the supported resources, alerts, permissions and organizational maintenance process rather than applying the example indiscriminately.
Action groups can be added across different alert sources
Not every Azure alert source exposes the same native action-group assignment options. Microsoft documents that alert processing rules can add action groups to supported fired alerts beyond the standard alert-rule workflow, including certain Azure Backup alerts. The distinction is useful when an operations team wants consistent routing across backup, compute and resource-health incidents without reimplementing the same notification policy in many services.
For a backup failure, the real underlying control is still the vault policy, protected workload state and restore verification. A notification only tells an operator that something needs attention. An appropriate Azure backup and recovery operating model defines who reviews the alert, how the condition is diagnosed, and what evidence demonstrates that a restore can still succeed.
Be cautious with broad add-action-group policies. Routing every alert into one overloaded queue can make critical failures less visible. Severity filtering, clear team ownership and useful action-group names should support triage, not merely increase message volume.
Troubleshoot missing notifications without hiding the real problem
When an alert fired but nobody received a notification, investigate in a fixed order rather than granting wider permissions or recreating all rules. Begin with the alert record, then identify its action-group assignment and any processing rules that may have changed that assignment.
| Observation | Potential cause | Next verification |
|---|---|---|
| No fired alert exists | Rule condition, evaluation window, signal, disabled rule | Inspect rule state and the underlying metric or log results |
| Alert exists, no actions invoked | Matching suppression processing rule or no action group | Review effective processing scope, filters, precedence and schedule |
| Action group selected, email absent | Recipient configuration, mail delivery or rate restriction | Test action group delivery to an approved recipient and inspect evidence |
| Webhook failed | Endpoint/network availability, authentication, schema, rate limit | Check the target’s response and the expected POST payload |
| Alert from one resource routes incorrectly | Broad processing scope or overlapping add-action rules | Compare resource ID, severity and all matching processing policies |
| Updated rule has no immediate effect | Propagation delay or an older alert | Allow the documented propagation window, then test a newly fired alert |
A Log Analytics workspace design determines where collected logs can be queried and governed, while data collection rules determine how selected telemetry enters and moves through the collection pipeline. Neither guarantees that an alert notification reaches a responder. Separate telemetry collection, query correctness, alert evaluation, action-group delivery and incident ownership during troubleshooting.
Measure alerting quality rather than only alerting volume
Monitoring needs an operating owner. Record the number of important alerts received, actionable incidents, delivery failures, false positives, repeated notifications, mean time to acknowledgment and the percentage of production services that have an appropriate on-call path. These measures give the team feedback about whether its rules and action groups are usable, not merely whether a configuration exists.
An alert that never notifies anyone because of an unintended suppression rule is a detection-and-response gap. An alert that pages everyone on every routine fluctuation is a different gap. A well-run system balances the cost of unwanted interruption against the risk of missing material service failures and continuously tests that balance as resources, applications and team ownership change.
For Microsoft Azure administrators, the durable skill is to explain the whole alert lifecycle: a specific signal is evaluated, a fired alert retains evidence of the condition, the right action group reaches the right responder, and carefully scoped processing rules modify notifications only when intended. Configuration should be demonstrated through observed alert and delivery results before the team considers it reliable.
