Automatically Route Azure Service Health Alerts to the Right Service Owners Using Agentic Logic Apps

As organisations increasingly utilise Azure services, operational control is often shared among various teams. The Azure Kubernetes Service (AKS) may fall under the platform team’s responsibilities, while the database team looks after Azure SQL. Meanwhile, application teams handle App Services and Logic Apps.

Azure Service Health is a fantastic tool that helps you stay updated about service problems, scheduled maintenance, health alerts, and security incidents. However, in many setups, notifications often land in a generic inbox or with a central operations team. This means someone must sift through the alerts and identify which team is responsible for the impacted service—only then can they forward the notification to the right people.

This approach might work fine in smaller environments, but it can quickly become cumbersome as the number of Azure services and teams increases.

In this article, we’ll guide you through creating an automated solution using Azure Service Health, Azure Monitor Action Groups, and an Autonomous Agent Logic App. This will help ensure notifications reach the teams accountable for the impacted Azure services without manual intervention.

• Set up Azure Service Health Alerts
• Activate a Logic App via an Azure Monitor Action Group
• Keep a directory of service-to-owner mappings
• Utilise an Autonomous Agent workflow for effective routing
• Automatically inform the relevant service owners
• Establish a fallback method for any unmapped services

Picture this: Azure Service Health sends out a notice regarding Azure OpenAI.

If you’re using the default settings, this notification might go to a central email like [email protected].

A member of the operations team now has to:

1. Look over the notification
2. Figure out which team oversees the affected service
3. Manually forward the email
4. Keep track of who has been notified

This adds extra work and can slow down reactions during crucial moments.

Our solution revolves around three Azure services:

1. Azure Service Health Alert
2. Azure Monitor Action Group
3. Azure Logic App (Autonomous Agent)

In this setup, the Logic App functions as the smart routing layer to decide who gets each service health notification.

To determine the right recipient for an alert, the Logic App refers to a service-to-owner directory. For instance, this mapping could be kept as a CSV file in Azure Blob Storage.

Services,Owners
Azure App Service,[email protected]
Azure SQL,[email protected]
Logic Apps,[email protected]
Azure OpenAI,[email protected]
Azure Kubernetes Service,[email protected]
Microsoft Sentinel,[email protected]
Default,[email protected]

Important: Always ensure to include a Default entry in your mapping file. If an alert arises for a service that isn’t specifically mapped, the notification will still reach a fallback operations team.

We’ve chosen to use Azure Blob Storage because it’s straightforward to set up and maintain, fitting most use cases.

That said, the Service Owner Lookup tool (details in Step-1 to create the Logic App) only retrieves ownership data. You can swap out the underlying data source to match your organisation’s requirements.

The key takeaway is that the Autonomous Agent doesn’t depend on where the data originates. As long as the lookup tool delivers a well-structured list of service-to-owner mappings, the routing logic remains intact.

This flexibility enables organisations to connect with existing governance systems, Configuration Management Databases (CMDB), service catalogues, or internal APIs without needing to change the workflow as a whole.

Instead of directly querying Blob Storage, the Autonomous Agent uses the output given by the Service Owner Lookup tool to decide the right recipients for incoming Service Health events.

Standard Logic App setups often rely heavily on multiple switch statements or conditions to manage routing logic.

As the number of services increases, keeping track of these conditions can become a real challenge.

This is where an Autonomous Agent proves its worth, simplifying design.

• Analyses incoming Service Health notifications
• Identifies the impacted Azure service
• Retrieves ownership details
• Selects the correct recipients
• Formats and sends out notifications

With this approach, upkeep usually means just updating the service owner mapping rather than altering the workflow logic.

For this setup, create a Consumption (Multi-Tenant) Logic App and choose an Autonomous Agent workflow. Below are the tools included in my autonomous agent, with a template for the Logic App provided in the deployment section below.

Interprets the Service Health payload received through the Action Group.

Fetches the service ownership mapping and identifies the right recipients.

Formats and sends notifications to the identified service owners.

Alerts Cloud Administrators if the workflow execution encounters issues.

The Logic App workflow should resemble the one below.

The Azure Monitor Action Group triggers the Logic App every time a relevant Service Health event is detected.

To configure this:

Azure Portal → Monitor → Alerts → Action Groups

You have the choice to create a new Action Group or modify an existing one.

Fill in the necessary details in the Basics section, then go to the Actions tab.

1. Select Logic App as the Action Type.
2. Choose the subscription that your Logic App is in.
3. Identify the resource group housing the Logic App.
4. Locate and select the Logic App you created in Step 1.
5. Opt for the HTTP trigger:
   • When an HTTP request is received
6. Provide a friendly title for the Action.
7. Save the Action Group.

Your setup should appear similar to the example below:

Important: Make sure the Logic App trigger selected in the Action Group is set to “When an HTTP request is received”. Choosing the wrong trigger could prevent the Service Health payload from reaching your workflow.

Tip: The notifications from Service Health use a specific payload format. The Logic App will receive the complete alert context through the HTTP trigger, enabling the Autonomous Agent to pinpoint the affected Azure service and determine which recipients to notify.

After saving the Action Group, Azure Monitor will automatically trigger the Logic App whenever a Service Health alert that matches your criteria arises.

To create a Service Health Alert, visit Azure Service Health.

• Subscription
• Services
• Regions
• Event Types
• Severity

Select Use an Existing Action Group and pick the Action Group you set up earlier.

It’s a good idea to keep the standard Azure Service Health email notifications on for a week or two post-deployment.

• Check Logic App execution
• Assess routing accuracy
• Confirm email delivery
• Test fallback scenarios

A sample deployment template to set up the necessary resources can be found on GitHub:

Azure-Service-Health-Alert-Automation

This solution is crafted using Azure services that generally follow a consumption-based or pay-as-you-go pricing structure. The total cost will depend mostly on how many Service Health notifications you receive, Logic App executions, connector usage, and any additional storage resources.

Azure Service Health is accessible to Azure subscribers without any extra fees.

Action Groups primarily serve to route notifications and perform automated actions. Some notification channels and actions might incur costs depending on the type and volume of notifications.

The article features a Consumption (Multi-Tenant) Logic App model. In this model, billing is based on workflow and trigger executions, connector actions, and related operations. This means costs will grow with actual usage, making it an economical choice for event-driven workloads like Service Health notifications.

Depending on how you set things up, additional charges might apply for:

• • Azure Blob Storage for holding service-owner mappings
  • Office 365 or Outlook connectors for email delivery
  • Custom connectors, APIs, or databases for owner lookups
  • Any monitoring or logging resources used for diagnostics

Tip: As Service Health events are usually infrequent in most setups, the operational cost of this solution is generally low. Nonetheless, it’s wise to check pricing for the services you’ll be using based on your Azure subscription and region.

Azure Service Health gives you essential visibility into platform events, but the real value of those alerts relies on whether they reach the right people who can act on them.

By combining Azure Service Health, Azure Monitor Action Groups, Blob Storage, and Autonomous Agent Logic Apps, you can develop a scalable notification-routing system that systematically delivers alerts to the teams managing the affected services.

The outcome is a reduction in manual tasks, quicker response times, increased accountability, and a much smoother operational framework for overseeing Azure environments on a larger scale.