Once you manage more than a handful of Azure resources, you have probably seen alerts pile up until nobody reads them anymore. In many of the environments I work in, this alert fatigue is a real problem, and it gets worse during maintenance windows or planned changes, when admins receive hundreds of notifications they never needed. People stop paying attention, and a genuine incident can slip past. Alert processing rules in Azure Monitor address exactly this. They let you suppress, reroute or modify alerts at scale before they ever reach your action groups.
Alert processing rules give you targeted control over fired alerts
In the Azure portal, alert processing rules (APR, sometimes still called Smart Detection Rules) live under Azure Monitor → Alerts → Alert processing rules. Their main advantage is timing: an APR takes effect immediately after an alert fires, and you can apply it to all resources or only to selected ones. I mostly use them to suppress alerts automatically during planned maintenance or to send notifications to a backup team for a while. They are also flexible on scheduling, so you can mute metric or log alerts during planned deployments, for example. I have covered related ground in my post on Azure Monitor Baseline Alerts in practice.
The diagram below shows where APRs sit in the flow relative to action groups:
flowchart TD
AlertGen["Alert triggered"] --> APR["Alert Processing Rule checked"]
APR -->|"Rule: suppress alert"| EndSuppressed["Alert suppressed"]
APR -->|"Rule: modify action group"| AG["Notify Action Group"]
AG --> Notify["Recipient notified"]
Figure: How an alert passes through an alert processing rule and an action group in Azure Monitor.
APRs are most useful when several teams share an environment, or when you don't want to wake the on-call engineer over something trivial during maintenance. I often suggest them for patch windows (Azure Update Manager or a similar tool), where routine and low-severity alerts get suppressed and only the critical ones come through. Because everything is managed centrally, you also avoid a pile of conflicting custom rules on individual resources.
Action groups need structure, scale and regular testing
Action groups carry the actual notification. They decide how and where an alert goes: email, SMS, push notification, webhooks or integrations through Logic Apps. In larger tenants they tend to multiply until nobody has an overview. I recommend organizing them by function (database, network, app) and by recipient (on-call, compliance, helpdesk). These combinations have worked well in projects I've been part of:
- Email to on-call or DevOps
- Logic App → Teams channel
- ITSM connector (e.g. ServiceNow)
- Automated Azure action (trigger Runbook)
Test your action groups on a regular basis. I keep running into critical alerts that went nowhere because someone renamed a Teams channel or an ITSM integration had expired. Under Azure Monitor → Alerts → Action groups you can send a test notification and check the entire chain. With Logic Apps you can add more complex escalation logic and formatting. The official docs list all action group options.
Practical tip: Record an owner and an expiry date for every action group in your ITSM system. When something stops working or a destination changes, you know right away who to talk to.
Severity and alert state decide which alerts really matter
Many teams treat every alert as if it were equally urgent. Azure Monitor gives you severity levels from 0 (Critical) to 4 (Verbose), and I strongly advise using that scale consistently and basing your alert processing rules on it. During maintenance, for instance, you can let severity 0 and 1 through and mute everything else. That cuts down on alert fatigue and keeps the ops team on the alerts that count.
You should also know the difference between stateful and stateless alerts. A stateful alert stays open until the condition clears (sustained high CPU, for example). A stateless alert fires again for every event. Most false positives during maintenance come from stateless rules, so you can point APRs at those rule types and suppress more precisely.
An alert processing rule takes five steps in the portal
To suppress alerts during maintenance, you create a new APR with a schedule and define which resources and severities it covers:
- Azure Monitor → Alerts → Alert processing rules → Create
- Select "Suppress alerts"
- Define schedule and target resources
- Optionally filter by severity
- Save and test
If you need to attach an action group to all alerts of a certain type (say, for a new SOC team), use "Add Action Group" in the same menu. It applies across the tenant for the resource types you choose.
Testing action groups is your safety net
I never put new action groups or APRs live without testing them against a simulated alert first. Under Azure Monitor → Alerts → Action groups → Test you can send a test notification to mail, a Logic App or an ITSM connector. Only after I have confirmed every recipient and workflow end-to-end do the rules go into production. To trace what happened to a particular alert, look at the Activity Logs or build your own monitoring logs for the alerting pipeline.
You'll find more on baseline alerts and on reducing alert fatigue in Azure Monitor Baseline Alerts in practice.
Alert processing rules are the fix for alert fatigue most teams overlook
In my view, alert processing rules are the most underused tool against alert fatigue in Azure. You control them centrally, they stop pointless notifications during maintenance, and they make it much easier for teams to work together. The more complex your alerting becomes, the more you depend on good documentation, regular tests and a sensible use of severity levels. If you set up APRs and action groups properly, you will get fewer alerts, and the ones you do get will actually mean something. Your ops team will be grateful.
