How to Use Azure Logic Apps to Create More Detailed Azure Monitor Alerts

If you manage Azure environments for multiple customers, you've probably noticed that default Azure Monitor alerts don't give you enough context. A standard alert notification tells you something fired, but it doesn't tell you which customer is affected, what subscription it came from, or what the actual query results look like.

In this guide, we'll show you how to use Azure Logic Apps to transform basic alert notifications into rich, actionable emails that include customer names, subscription details, and embedded query results.

Two Deployment Models

There are two ways to architect this solution depending on your requirements:

Model 1: Customer Tenant Deployment

Both the Azure Monitor alert and the Logic App run inside the customer's tenant. The customer bears all execution costs, and you monitor everything within their environment.

Model 2: Hybrid Deployment (Recommended)

The Azure Monitor alert runs on the customer's tenant, but the Logic App runs on your partner tenant. Triggers use secure webhooks to avoid unauthenticated exposure. You bear the Logic App execution costs while the customer pays for their Azure Monitor alerts.

We recommend Model 2 for most partner scenarios because it centralizes your automation logic and uses secure webhooks for cross-tenant communication.

Understanding Common Alert Schema

Azure's Common Alert Schema provides a standardized JSON structure for all alert notifications — whether they come from activity logs, metrics, or log alerts. This eliminates the need to maintain separate templates for each alert type and makes your Logic App workflow consistent regardless of the source.

Enable Common Alert Schema in your Action Groups to take advantage of this standardization.

Building the Logic App

Required Components

Your Logic App will use several connectors and actions:

• HTTP connector — Makes API calls to retrieve supplementary data (subscription names, tenant info)

• Azure Monitor Logs connector — Re-executes Kusto queries to embed results in emails

• Variables — Stores extracted data like subscription names, resource groups, and severity levels

• Data Operations — Generates HTML tables from query results

• Office 365 Outlook — Sends the formatted email notifications

• Control flow — Switch statements to handle different monitoring service types

Step 1: Set Up the HTTP Trigger

Create a new Consumption-plan Logic App in the Azure Portal. Add a "When an HTTP request is received" trigger and generate the schema using a sample Common Alert Schema payload. Save the Logic App to generate your HTTP POST URL — you'll need this for the Action Group configuration.

Step 2: Initialize Variables

Set up variables to store contextual information extracted from the alert payload:

• Affected Resources — Array extracted from the alert's target resource IDs

• Customer Subscription ID — Parsed from the resource path

• Fired Time — Formatted from ISO 8601 to a readable date/time string

• Customer Name — Identifies which customer this alert belongs to

• Alert Severity, Description, and Rule Name — Core alert metadata

• Customer Subscription Name — Retrieved via Azure Management API call

Step 3: Extract Resource Information

Use a split expression on the alert target ID to parse out the subscription ID, resource group, and workspace name:

```

split(triggerBody()?['data']?['essentials']?['alertTargetIDs'][0], '/')

```

This gives you array indices for subscription ID (index 2), resource group (index 4), and workspace name (index 8).

Step 4: Format the Fired Time

Convert the ISO timestamp to something human-readable:

```

formatDateTime(triggerBody()?['data']?['essentials']?['firedDateTime'],'MMMM-dd, yyyy HH:mm:ss')

```

This transforms timestamps into a format like "July-12, 2023 05:27:38".

Step 5: Handle Alert Types with Switch Control

Azure Monitor has nine possible monitoring service types, and the alert context structure varies for each. Use a Switch control to handle each type appropriately — Activity Log alerts, Metric alerts, Log Analytics alerts, Application Insights alerts, and others all have different context schemas.

Step 6: Re-Execute the Kusto Query

Use the Azure Monitor Logs connector's "Run Query and List Results" action to re-execute the original Kusto query. This embeds the actual results directly in the email, so recipients don't have to click through to the Azure Portal.

Step 7: Build the HTML Email

Use the Data Operations "Create HTML Table" action to convert query results into a formatted table. Apply CSS styling with a replace expression:

```

replace(body('Create_HTML_table'),'

', '')

```

Then insert all your variables — customer name, subscription details, severity, fired time, and the query results table — into an HTML email template.

Step 8: Send the Email

Use the Office 365 Outlook "Send Email V2" action to deliver the formatted alert to your team.

Setting Up the Azure Monitor Side

Create the Alert Rule

Write your Kusto query targeting the relevant log table. For example, to monitor failed sign-in attempts, query the SigninLogs table and filter by specific error codes, summarizing by user, device, location, and attempt count.

Configure the Action Group

Create an Action Group in Monitor > Alerts > Action Groups. Set the action type to Webhook, enable Common Alert Schema, and paste your Logic App's HTTP trigger URI.

The Result

Instead of a generic "Alert fired" email, your team receives a rich notification that includes the customer name, subscription details, alert severity, a direct link to the query in the Azure Portal, and the actual query results embedded in the email body. No more guessing which tenant is affected or logging into multiple portals to investigate.

Next Steps

This pattern is highly customizable. You can adapt the HTML template, add additional API calls for richer context, or integrate with other notification channels. Experiment with different Kusto queries and monitoring scenarios to build alerts that give your team exactly the information they need to act quickly.

Contact CelesteTek if you need help with Azure infrastructure monitoring or building AI automation workflows across your environments.