Are your Azure alerts reaching the right people? Inside Azure Support Agent's Alerts Manager

An alert rule exists. It is enabled. It has an Action Group attached.

That is a useful start, but it is not the whole operational question.

Which conditions does it cover, where is it configured to send notifications, and does that route still match the team responsible for responding?

Azure Monitor exposes the ingredients: signals, alert conditions, fired instances, Action Groups, and notification actions. Azure Support Agent's Alerts Manager brings those relationships into a common review workflow. You can inspect the configuration, investigate a gap or overlap, and prepare a controlled correction without treating a promising diagram as proof of delivery.

The goal is not simply fewer alerts. It is alerting you can explain.

This continues the workbench introduced in the first article. The War Room investigates incidents; the architecture article maps the workload. From here, the articles focus on individual operational workflows, starting with the alerting around that workload. You do not need to read the earlier posts to follow this one.

About the animations: every GIF shows native Alerts Manager components with fictional Contoso Booking data supplied entirely inside an isolated browser. They are edited walkthroughs, not performance measurements. Change outcomes are simulated; no backend records, Azure changes, real alert events, or notifications were created. Persistent labels identify the synthetic data.

Watch the Alerts Manager tour

This faster-paced, approximately 60-second tour visits the ten Alerts Manager tabs, from the overview and alert instances to notification paths, overlap review, gaps, rule analysis, editors, deployment plans, and managed changes. It is a tour of this feature, not a compressed tour of the whole workbench. Watch the chapter captions, then use the shorter animations below to examine each decision more closely.

Alerts Manager tour: synthetic data throughout. Its continuous-motion pacing is editorial, not a measurement of Azure collection or application performance.

Start with the route, not the rule count

Imagine reviewing the alerting for a hotel booking workload before a busy travel period. There is no incident. The application is operating normally. This is the moment to ask whether the next operational event will reach the people expected to handle it.

A rule count cannot answer that question. A route can help:

Monitored resource or scope → alert rule → Action Group → receiver or automated action.

An alert rule defines what Azure Monitor evaluates. A fired alert instance records an occurrence. An Action Group collects notification and automation actions, email recipients, webhooks, and other supported destinations. The same Action Group can serve several rules, and a rule can reference several Action Groups.

Those shared relationships are useful. They also mean the name of the group is not enough. An Action Group called oncall may contain several destinations; a second group may share one of them. You need to inspect the recipients and the rules using them before deciding whether that arrangement is intentional.

Follow the fictional Booking on-call group into its editor. The recipient addresses are synthetic; opening the editor neither sends a notification nor saves a configuration change.

In Alerts Manager, start with the intended connection and a workload, subscription, or management-group scope. Check the age and completeness of the available data before drawing conclusions. The analysis report and the rule/Action Group inventory have separate refresh paths; a report you saved earlier is not automatically a fresh reading of Azure.

Then open Visualize.

The view assembles the configured paths from resources and rules through Action Groups to receivers. It can make a disabled rule, a group with no active receiver, or a destination referenced from several groups much easier to investigate than a list of names.

The important label is expected delivery. It means the configuration represented in the model supports that path, not that a message was sent or received.

How to work the Visualize screen

The useful way to read Visualize is from the selected scope toward the destination. First establish which resources belong in the review. Then follow the alert that monitors them, the Action Group it references, and the receivers reached through that group. The outcome column summarizes what the configuration model expects for those paths.

Do not begin by looking for a reassuring green total. Begin with a resource or rule whose purpose you understand. That gives you a reference point against which to challenge the view.

Select a rule, focus its path, change the grouping and density, narrow to metric rules, and inspect route rows. All underlying responses are synthetic; the interactions are native UI.

Follow a path before changing a filter

Click a rule name, icon, vertical bar, or connecting segment. The explorer highlights complete paths associated with that selection while unrelated relationships recede. This is particularly useful when one Action Group serves several applications: you can examine the selected rule's route without mentally following every ribbon in the estate.

Use the search box to focus on a known rule, resource, group, or receiver. A precise name is usually more useful than a broad term shared by half the application. In the animation, Booking API errors is a better starting point than Booking, because it isolates the question rather than highlighting nearly everything.

Search and selection help you read the existing graph. They do not establish that the source inventory is complete, and they do not prove that a rule fired. Keep those evidence questions separate from the navigation technique.

Three controls answer three different questions

The screen has several ways to narrow what you see, but they are not interchangeable.

Scope asks which workload, subscription, or management group you are reviewing. Changing that boundary can trigger new collection. It is the right place to start when the question concerns a different application's resources, not just a different arrangement of the picture.

Rule filters ask which configured rules you want to inspect within the loaded inventory. Family, severity, enabled state, Activity category, and the category's condition fields narrow that set. These filters operate locally after the routing data has loaded. The filtered-rule indicator helps explain why the graph changes when you make a selection.

Display controls ask how to make those relationships readable. Group by resource type, resource group, or alert state; switch between detailed, compact, and summary density; inspect resources with no alert or a modeled flow gap. These are lenses over the loaded information, not corrections to the underlying Azure configuration.

The distinction matters when sharing results. A visually simplified graph can be easier to read without representing a different source inventory. Do not describe a display change as having removed rules or fixed a gap.

Use the picture to find the row

The graph is the fastest way to notice a relationship. The Notification routes table is where you inspect it precisely: resource, rule, Action Group, receiver, payload schema, modeled outcome, and any recorded issues. Follow that with Routing diagnostics when a path needs explanation.

A legacy destination with no active receivers deserves a different investigation from a cross-subscription group that the connection could not inspect. The first may be a configuration problem; the second may require better visibility before any conclusion is possible. Replacing an unreadable group without checking it could create new work while removing a valid route.

Use zoom and Fit when the canvas becomes dense, but keep names and conditions readable rather than forcing the entire estate into one tiny picture. For an operational handoff, a focused path with its supporting row is more useful than a screenshot containing every resource.

Finally, review the export boundary. Local rule filters affect the Visualize CSV and JSON, but graph-only display filters and the route-table search are not the same export filter. Confirm the exported rows before sharing them. A screen that shows one highlighted receiver does not mean the downloaded file contains only that receiver.

A small condition can explain a missing notification

For our teaching scenario, suppose the workload's Resource Health alert is intended to tell the operations team both when a resource becomes unhealthy and when its reported health returns to Available.

Now suppose the existing rule's Current resource status condition includes Degraded and Unavailable, but not Available.

The rule can be enabled, its Action Group can have the right recipients, and the route can look sensible. It still does not select an event whose current resource status is Available. The condition is narrower than the team's intended notification policy.

That is not an Azure failure. It is a configuration decision worth making visible and checking against operational intent.

In Visualize, choosing the Resource Health Activity category exposes the relevant filters: event status, current resource status, previous resource status, and reason type. They let you ask a more precise question than “do we have a Resource Health rule?”

The counts are derived from the conditions collected for the rules. They do not assume that an existing rule uses the defaults offered when creating a new one. If a value has no matching rules in the loaded view, inspect the source conditions, and the collection's scope and completeness, before concluding that it is absent everywhere.

Once the routing inventory is loaded, changing these category filters operates locally in the browser. It narrows the view without a new estate collection for each selection. Changing scope or explicitly refreshing the simulation is different: those actions can read Azure again.

Service Health has its own event-type choices: Service issue, Planned maintenance, Health advisories, and Security advisories. These are a different question from a resource's health state. A rule for maintenance is not interchangeable with a rule for service incidents merely because both appear under Service Health.

There is another distinction to keep straight: a Resource Health event reporting Available is not the same thing as a metric alert's Resolved notification. Azure's alert families have different state behavior. The bulk routing view does not establish every rule's resolved, muted, or throttled notification behavior; those need separate rule-level and Azure review.

Filter the fictional Resource Health rule, inspect its missing Available condition, then use the native context menu to open the editor. The form is inspected, not submitted.

An overlap is a question, not a deletion instruction

While tracing routes, you may find another kind of concern: two rules inspecting a similar signal, or multiple paths reaching the same receiver.

Alerts Manager's Overlaps view places the candidate rules, their signal/target, and their notification relationship together. It is a starting point for deciding whether those rules duplicate work or intentionally provide different layers of response.

Consider two possibilities:

• A warning rule notifies the application team; a more severe rule also reaches the platform on-call team. Shared scope does not make one redundant.
• Two rules have accumulated around the same operational condition and both reach the same destination. That may merit consolidation, but only after comparing the full conditions, thresholds, windows, recipients, and observed firings.

The picture alone cannot tell you which organizational intent is correct.

Compare the fictional overlapping rules with their rule-analysis rows. Shared destinations are review evidence, not proof that duplicate incident notifications were delivered.

If an overlap is intentional, Accept overlap records that decision and its reason in the application. It does not edit Azure or approve a deployment. That is valuable in its own right: the next reviewer should not need to rediscover why a deliberate escalation layer exists.

For a genuine issue, prefer the smallest justified correction. A wrong receiver or a missing condition does not automatically justify disabling the whole rule. Making a dashboard quieter is not the same as making the workload better monitored.

From a route to a reviewed correction

Return to our hypothetical Resource Health rule. The team confirms that notifications for Available events belong in its response procedure. The intended change is narrow: include that status while retaining the other reviewed conditions and destinations.

A rule or Action Group node in Visualize is also an entry point to its editor. Right-click the node, or use the keyboard context menu, and choose Edit rule or Edit Action Group. If several connected objects could be meant, an inline selection identifies the exact target.

The application opens the existing editor with that resource loaded. Read-only connections and missing management permissions are explained as locked actions. Opening the editor is a read; it is not an Azure update.

The Activity Log editor presents condition controls for the selected category. For Resource Health, review current status alongside the event status, previous status, and reason type. Adding Available is only the intended correction if the remaining conditions also match the events the team wants to know about. There is no universally correct “select everything” rule.

Before submitting, verify:

• The connection, subscription, resource group, and exact rule identity.
• The monitored scope and all the conditions, not just the field being changed.
• Enabled state, Action Groups, and their intended operational owners.
• The reason for the change and how its result will be checked.

Then Validate & create change creates a managed request. The desired configuration and the captured prior state are retained in encrypted fields; the request begins pending. It has not changed the Azure rule.

This is where the Azure Support Agent turns analysis into an operational workflow rather than leaving the finding in a report.

The change reason should be more useful than “fix alert.” State the intended event coverage, the accountable team, and the evidence that would demonstrate success. For this example, the reason is to include Available events while preserving the reviewed unhealthy-event conditions and destinations. That makes the proposal understandable to someone who did not sit beside the author while the form was edited.

Also check the breadth of the proposed change. Editing one rule's Action Group reference affects that rule; editing a shared Action Group's recipients can affect every referencing rule. Both may be appropriate, but they need different impact reviews. The graph helps reveal that distinction before a small-looking form edit becomes a much broader notification change.

Approval is not apply

The separation is explicit:

This animation models the lifecycle inside the browser. The native UI changes from pending to approved to applied, but no request reaches a backend or Azure. It is not evidence that real approval enforcement or a real configuration update succeeded.

Managed rule and Action Group requests do not silently auto-apply because autonomous chat has a more permissive configuration. Their approval and apply steps remain separate.

Two permission boundaries matter. The operator needs the relevant application permission to propose or approve the action, while the connection identity needs the corresponding Azure permissions at the target. A product approver cannot override a read-only connection or create Azure rights that the connection does not possess.

Use an independent reviewer where your operating process requires one. Alerts Manager records requester and decision metadata, but it does not itself enforce a different requester and approver or a second approval based on a risk label.

There is also a practical reason not to leave approval until after thinking about verification: an approval authorizes an attempt. It cannot guarantee that Azure will accept the operation, or that the selected condition will produce the response the team intended.

What if someone changed the rule while we were reviewing it?

That is normal in a real estate. A portal edit, an infrastructure deployment, or another operator may have changed the rule after the request captured its prior state.

Before an update or deletion, the apply path reads the current resource and compares its normalized state with the request's expected-state hash. If they differ, it refuses that outdated request and reports a conflict rather than knowingly overwriting the newer state.

Refresh, inspect the intervening change, and prepare a new proposal. A stale result is not an instruction to keep clicking Apply.

This is an application-level pre-apply check, not an atomic lock on Azure. It helps detect a change that happened during review; it does not remove the need to coordinate concurrent portal and infrastructure-as-code changes.

Verify the configuration, and then verify the destination

After a supported apply completes, the manager records the outcome, associates an evidence snapshot, and invalidates affected inventory caches. Return to the rule inventory and run Analyze again so the assessment reflects the new configuration.

For our hypothetical change, verification would mean reading the actual Resource Health rule back from Azure and confirming that:

1. Available is present in the intended current-status condition.
2. The other reviewed conditions, scope, enabled state, and Action Group references remain correct.
3. A refreshed routing view represents the intended configuration without unresolved source warnings.

That establishes a configuration result. It still does not establish that a matching event occurred or that a human received a notification.

Keep a short verification note with the change: the source read time, exact rule, relevant conditions, and the destination checked. If the readback differs from the reviewed proposal, stop and explain the difference before declaring success. If the inventory is still stale or partially collected, record that as unfinished verification rather than rounding the result up to complete.

This is also why comparing only dashboard totals is weak evidence. A gap count can change because the scope changed, a source became unreadable, or a baseline was updated. A useful before-and-after comparison holds those inputs steady and checks the particular rule that was meant to change. The count supports the story; it does not replace it.

Azure offers Action Group testing, and Alerts Manager exposes an explicit Test action. It requires the dedicated permission, a writable connection, and the confirmation SEND TEST. This is not another dry-run view: it attempts real delivery to the group's configured receivers and actions. An automated receiver may start a workflow, not merely display a message.

Use a deliberately approved test destination and coordinate with its owners. Inspect completion and the receiving mailbox, endpoint, or workflow. Accepted or Running is not a completed delivery result.

Even a successful test establishes only the tested path at that moment. It does not prove that every future rule condition will match, that every downstream system will remain available, or that the on-call process will respond correctly.

The sequence is configuration review → reviewed change → source-state verification → separately authorized delivery verification. Each answers a different question.

A rollback is another reviewed change

For supported applied operations, Prepare rollback creates a new pending request based on the retained prior state. It does not instantly undo Azure. The inverse must be reviewed, approved, applied, and verified too.

Not every prerequisite has a safe automatic inverse. A resource group created for an alerting plan may later contain unrelated resources, so automatic resource-group deletion is deliberately unsupported. Action Group removal also requires dependency review.

The useful promise is a visible, reviewable recovery path where supported, not an undo button for every possible Azure side effect.

When the right rule does not exist yet

Our example corrects an existing route. Sometimes the review discovers there is no matched rule for a recommended signal at all.

That is where Gaps connects Alerts Manager to Azure Monitor Baseline Alerts, Microsoft's published monitoring guidance. The questions complement each other:

• Coverage: what monitoring does the selected baseline expect?
• Management: what do the existing rules and routes do, and which change should be reviewed?

Selected supported static-metric gaps can become a deployment plan attached to a healthy live Action Group. The preview exposes the metric, aggregation, threshold, dimensions, target, severity, and evaluation settings before submitting any child changes.

The gap path checks Azure's live metric-definition catalog, using a representative resource per type. An unreadable catalog, absent metric, or unsupported requested dimension becomes a blocker; aggregation may be normalized to a supported value. This catches important mistakes early, but is not an exhaustive deployment test of every resource and API constraint.

Current generated metric proposals are enabled on apply. Review that setting deliberately; creating the plan is not the same as deploying a harmless disabled placeholder.

Blocked items remain work to resolve. Submitted items become pending requests and follow the same separate approval and apply workflow. Do not treat every baseline recommendation as an automatically deployable alert.

Review a fictional missing baseline, then inspect its saved plan and chosen Action Group. The plan is synthetic and no validation, submission, or deployment was sent to Azure.

Beyond one workload: keep destinations explicit

At a management-group scale, “use the monitoring resource group” is ambiguous. Each selected subscription may have its own destination, and some may not have that group yet.

The Essential Activity Log coverage workflow addresses this for Service Health, Resource Health, Security, and Recommendation alert categories. It requires explicit subscription selection and destination mapping rather than inferring permission to change every subscription that might exist beneath the management group.

Routing can use a healthy visible central Action Group, same-subscription overrides, or explicitly planned local clones. “Healthy” here reflects the inspected configuration; it is not a delivery test. Verify Azure's family and processing-region requirements as well, for example, current Microsoft guidance requires a Global Action Group for Service Health alerts.

If new infrastructure is needed, the plan represents it as separate requests:

Resource group prerequisite → Action Group prerequisite → dependent alert rule.

The backend resolves those dependencies for approval and apply, including prerequisites that are not on the current page. A failed prerequisite blocks its dependent branch while independent branches can continue. Inspect the resulting applied, skipped, and failed outcomes; a batch is not an all-or-nothing transaction.

This is the same operational discipline as the single-rule correction, applied to more targets: explicit destination, explicit proposal, and a result you can reconcile.

One boundary is easy to miss: Activity Log notifications are not Activity Log ingestion. Configuring a Security-category alert does not silently export logs to a SIEM or workspace. Diagnostic-setting changes are a separate workflow with their own review and possible costs.

Cost is useful context, not the reason to remove coverage

Alerts Manager places reference cost estimates alongside rule analysis. That can help frame a review of duplicate-looking rules, evaluation settings, or potential cost if disabled rules are enabled.

Treat those figures as estimates from a versioned pricing reference, not as your Azure bill. Unknown or unpriced entries are not free. A direct rule-cost classification also does not include every downstream notification, workflow, or ingestion cost.

Open the illustrative cost breakdown and inspect category coverage. These are synthetic figures, not measured production outcomes or an Azure billing quote.

The objective is not the lowest rule count or the cheapest dashboard. It is justified coverage with understood routing and an accountable response. Verify any claimed savings against billing and the actual change, not just the difference between two estimates.

What the model does not prove

The core routing view is built from collected configuration. It is not a language model guessing who should be on call. That distinction matters in an AI workbench: use AI where interpretation helps, but keep configuration relationships and change decisions inspectable.

There are still limits worth keeping in view:

• Unreadable is not absent. A cross-subscription Action Group outside the connection's visibility may exist and work. Resolve missing access or partial collection before replacing it.
• Expected routing is not complete delivery behavior. Alert Processing Rules, suppression, receiver-side handling, platform requirements, and rate limits need separate review. The current Alerts Manager does not provide Alert Processing Rule suppression-window management.
• Firing history has a window. The stored analysis currently collects seven days of firings; a displayed 30-day column is not evidence of a complete 30-day analysis. Confirm the source and period rather than treating every chart as the same dataset.
• Some actions are immediate. Acknowledge/close/reopen changes the alert's user-response state in Azure; it does not fix the resource or suppress future alerts. Notification tests are also immediate actions, distinct from managed rule changes.
• Exports are operational data. They can include full recipient addresses and other identifiers. Review and redact them before sharing outside the authorized audience.

These distinctions make the tool more useful, not less. An operator needs to know whether a result is a configuration fact, a model prediction, a recorded event, or a verified outcome.

How it's judged

An Alerts Manager review has done its job when you can answer:

• What is in scope? The workload or subscriptions, selected connection, source age, and collection limits are clear.
• Why does this route exist? The rule condition, Action Group, and receiver relationship can be traced to the underlying configuration.
• Why change it, or keep it? The decision includes operational intent, not just an overlap badge.
• What was authorized and executed? Pending, approved, applied, failed, and stale are not collapsed into one success label.
• What was independently verified? Azure configuration was checked separately from any actual receiver test, and unknowns remain documented.

That is a better outcome than “we deleted some alerts.” It is a record of why the remaining alerting matches the workload's needs, and where more evidence is still required.

For a team adopting this workflow, the first useful deliverable is a small routing register, not an estate-wide cleanup project. Record the workload, rule, intended event, accountable team, destination, and last verification date. Add a short note for intentional overlaps and anything that could not be inspected. That gives the next reviewer a starting point without turning this application into the only place where operational knowledge lives.

Revisit the register after ownership changes, major deployments, or notification incidents. The question is whether the configuration still matches the response procedure, not whether last month's screenshot looked healthy. Preserve unresolved questions alongside completed checks so uncertainty does not disappear between review meetings.

Try it on one route

Start with a small read-first review:

1. Open Alerts Manager in the Azure Support Agent, choose one workload or subscription, and confirm the selected connection and source freshness.
2. Open Visualize, choose a relevant rule family or Activity category, and trace one route.
3. Inspect its full rule conditions and Action Group destinations. Record what the route is intended to achieve, including anything the current view cannot establish.
4. Check a related overlap or gap. Decide whether it is intentional, needs more evidence, or merits a narrowly scoped change proposal.
5. Stop there unless a change or test is explicitly authorized. A useful review does not have to mutate Azure to be worth doing.

The Alerts Manager reference and operations guide cover the detailed permissions, supported editors, deployment plans, and recovery procedures.

The Azure Support Agent is open source. Use the installation guide to review the deployment before creating resources. Hosting and connected Azure/model services can incur charges; self-hosting does not eliminate those costs.

The next incident may still begin with an alert. The improvement is knowing why it should fire, where it is configured to go, and how you verified the path, before that incident begins.