Migrating from Pester 5 to 6
July 5, 2026
Hardware Voice Assistant for OpenClaw
July 6, 2026
As organizations adopt more Azure services, operational ownership naturally becomes distributed across multiple teams. The platform team may own Azure Kubernetes Service (AKS), the database team may manage Azure SQL, while application teams are responsible for App Services and Logic Apps.
Azure Service Health provides an excellent way to stay informed about service issues, planned maintenance, health advisories, and security events. However, in many environments, all notifications are sent to a shared mailbox or central operations team. Someone must then manually determine which team owns the affected service and forward the alert to the appropriate stakeholders.
While manageable for a small environment, this quickly becomes inefficient as the number of Azure services and teams grows.
In this article, we’ll build an automated solution using Azure Service Health, Azure Monitor Action Groups, and an Autonomous Agent Logic App that intelligently routes notifications to the teams responsible for the impacted Azure services.
What You’ll Learn
- Configure Azure Service Health Alerts
- Trigger a Logic App using an Azure Monitor Action Group
- Maintain a service-to-owner mapping repository
- Use an Autonomous Agent workflow for intelligent routing
- Automatically notify the appropriate service owners
- Implement a fallback mechanism for unmapped services
The Challenge
| Azure Service | Service Owner |
|---|---|
| Azure App Service | Application Team |
| Azure SQL | Database Team |
| Azure Kubernetes Service | Platform Team |
| Azure OpenAI | AI Operations Team |
| Microsoft Sentinel | Security Team |
Now imagine Azure Service Health generates an advisory for Azure OpenAI.
By default, the notification may be sent to a generic mailbox: cloudops@contoso.com
A member of the operations team must then:
- Review the notification
- Determine who owns the affected service
- Forward the email manually
- Track who has been notified
This introduces operational overhead and can delay response times during critical events.
Solution Overview
The solution consists of three Azure services:
- Azure Service Health Alert
- Azure Monitor Action Group
- Azure Logic App (Autonomous Agent)
Service Owner Mapping
To determine who should receive an alert, the Logic App uses a service-to-owner mapping.
In this example, the mapping is stored as a CSV file in Azure Blob Storage.
Services,Owners
Azure App Service,ASPOwners@contoso.com
Azure SQL,DBAOwners@contoso.com
Logic Apps,LAOwners@contoso.com
Azure OpenAI,OpenAIOwners@contoso.com
Azure Kubernetes Service,AKSOwners@contoso.com
Microsoft Sentinel,SentinelOwners@contoso.com
Default,CloudAdmins@contoso.com
Flexible Service Owner Data Source
This solution uses Azure Blob Storage because it’s simple to implement, easy to maintain, and suitable for most scenarios.
However, the Service Owner Lookup tool (More information in Step-1 Build the logic app) in the Logic App is only responsible for retrieving ownership information. The underlying data source can be replaced with any repository that best fits your organization’s architecture.
| Alternative Source | Implementation Approach |
|---|---|
| SharePoint List or File | Replace the Blob Storage action with a SharePoint connector action. |
| Azure File Share (SMB) | Use a File connector instead of a Blob connector. |
| Logic App Parameters | Store a small owner mapping directly within the Logic App or ARM template parameters. |
| HTTP API / Database | Query an internal REST API, CMDB, Azure Storage Tables or SQL database dynamically. |
The key point is that the Autonomous Agent doesn’t care where the information comes from.
As long as the lookup tool returns a structured list of service-to-owner mappings, the routing logic remains unchanged.
This flexibility allows organizations to integrate with existing governance platforms, CMDB systems, service catalogs, or internal APIs without modifying the overall workflow.
Why Use an Autonomous Agent?
Traditional Logic App implementations often rely on numerous switch statements and conditions to determine routing logic.
As service inventories grow, maintaining those conditions becomes increasingly difficult.
Using an Autonomous Agent greatly simplifies the design.
- Analyzes incoming Service Health events
- Identifies the impacted Azure service
- Retrieves ownership information
- Selects the correct recipients
- Formats and delivers notifications
Maintenance typically becomes as simple as updating the service owner mapping rather than modifying workflow logic.
Step 1: Build the Logic App
For this implementation, create a Consumption (Multi-Tenant) Logic App and select an Autonomous Agent workflow. I have added below tools to my autonomous agent. The template for the logic app is provided in the deployment section below.
Trigger Input Reader
Reads and interprets the Service Health payload received through the Action Group.
Service Owner Lookup
Retrieves the service ownership mapping and identifies the correct recipients.
Send Alert Email
Formats and sends notifications to the identified service owners.
Failure Notification
Notifies Cloud Administrators if workflow execution fails.
The logic app workflow should look like below.
Step 2: Configure the Azure Monitor Action Group
The Azure Monitor Action Group is responsible for invoking the Logic App whenever a matching Service Health event occurs.
Navigate to:
Azure Portal → Monitor → Alerts → Action Groups
You can either create a new Action Group or modify an existing one.
Provide the required information in the Basics section and then navigate to the Actions tab.
Configure the Logic App Action
- Select Logic App as the Action Type.
- Select the subscription where the Logic App is deployed.
- Select the resource group that contains the Logic App.
- Select the Logic App created in Step 1.
- Choose the HTTP trigger:
- When an HTTP request is received
- Provide a friendly name for the Action.
- Save the Action Group.
Your configuration should look similar to the example below:
Once the Action Group is saved, Azure Monitor will automatically invoke the Logic App whenever a Service Health alert matching your configured criteria is generated.
Step 3: Create the Service Health Alert
Navigate to Azure Service Health and create a Service Health Alert.
- Subscription
- Services
- Regions
- Event Types
- Severity
Select Use an Existing Action Group and choose the Action Group created earlier.
Validation and Testing
Keep the native Azure Service Health email notifications enabled for a week or two after deployment.
- Validate Logic App execution
- Validate routing accuracy
- Verify email delivery
- Test fallback scenarios
Deployment Template
A sample deployment template that provisions the required resources is available on GitHub:
Azure-Service-Health-Alert-Automation
Post-Deployment Requirement
After deployment, navigate to the Office 365 connection resource and complete the authorization process. This OAuth step is required before email notifications can be sent and cannot currently be automated through ARM template deployments.
Cost Considerations
This solution is designed using Azure services that generally follow either a consumption-based or pay-as-you-go pricing model. The overall cost of the implementation depends primarily on the number of Service Health notifications received, Logic App executions, connector usage, and any supporting storage resources.
Azure Service Health
Azure Service Health is available to Azure subscribers at no additional cost.
Azure Monitor Action Groups
Action Groups themselves are used to route notifications and automation actions. Certain notification channels and actions may incur charges depending on the notification type and usage volume.
Azure Logic Apps
This article uses a Consumption (Multi-Tenant) Logic App. In the Consumption model, billing is based on workflow executions, trigger executions, connector actions, and related operations. As a result, costs scale with actual usage, making it a cost-effective option for event-driven workloads such as Service Health notifications.
Supporting Services
Depending on your implementation, additional charges may apply for:
- Azure Blob Storage used to store service-owner mappings
- Office 365 or Outlook connectors used for email delivery
- Custom connectors, APIs, or databases used for owner lookups
- Any monitoring or logging resources used for diagnostics
Official Pricing References
Conclusion
Azure Service Health provides valuable visibility into platform events, but the effectiveness of those alerts depends on whether they reach the people who can act on them.
By combining Azure Service Health, Azure Monitor Action Groups, Blob Storage, and Autonomous Agent Logic Apps, you can build a scalable notification-routing solution that automatically delivers alerts to the teams responsible for the affected services.
The result is less manual effort, faster response times, improved accountability, and a more efficient operational model for managing Azure environments at scale.