Suggest a cost-effective way to send Azure AppInsights production errors to MS Teams.

Question

Suggest a cost-effective way to send Azure AppInsights production errors to MS Teams.

Deepika 40

Title: How can I send Application Insights production exceptions to Microsoft Teams?

I have a .NET Core application monitored with Azure Application Insights. I have created a dashboard showing exceptions by type and count, and I already have alerts working for SMS notifications.

Now I want to automatically send production application errors from Application Insights to a specific Microsoft Teams channel so my development team is notified.

What is the recommended Microsoft-supported setup for:

Application Insights → Azure Monitor Alert → Action Group → Microsoft Teams

Should I use a Logic App or another approach to send the exception details (exception type, message, timestamp, and Application Insights link) to Teams?

Please provide the recommended configuration steps.

0 comments

2 answers

Your answer

Answer 1

The Microsoft-supported, cost-effective setup is:

Create an Azure Monitor alert rule on the Application Insights resource for production exceptions or failed requests.
Create an Action Group that triggers a Logic App.
In the Logic App, use the Microsoft Teams action Post message in a chat or channel to send the alert details to the target Teams destination.
Avoid classic Teams incoming connectors for new implementations. Microsoft 365 connectors are nearing deprecation, and Teams guidance points to Workflows/Power Automate-based webhook workflows instead.

Recommended configuration path:

In Azure portal, open the Application Insights resource for the production app.
Go to Alerts in the left navigation and select Create an alert rule.
Choose the signal that matches the failure type being monitored:
- Failed requests for request/run failures.
- Dependency call failures if the issue is tied to dependency/action/trigger failures.
Set the threshold and evaluation frequency for the alert.
Create or select an Action Group.
In the action group, configure it to trigger the Logic App.
In the Logic App designer, add the Teams action:
- Search for Post message in a chat or channel.
- Under Microsoft Teams, select Post message in a chat or channel.
- Sign in to Teams when prompted.
- Set Post as to User.
- Set Post in to the required destination supported by the action.
- Select the target chat/channel.
Build the Teams message by combining static text with alert payload fields from Dynamic content. The documented examples include fields such as:
- alertRule
- severity
- firedDateTime
Save the Logic App.
Finish the alert rule by setting name and severity, then review and create it.

For the message body, include the exception summary and alert metadata from the payload. A practical Teams message format is:

Alert name
Severity
Fired time
Exception type/message if present in the payload
A pointer back to Application Insights for investigation

If richer exception details are required beyond the standard alert payload, use the Logic App to process the alert payload and format the Teams post accordingly.

Why this is the recommended approach:

Azure Monitor supports alert rules with Action Groups.
Logic Apps are documented for customizing alert notifications.
Teams posting is supported through the Post message in a chat or channel action.
Teams guidance indicates moving away from classic connector-based webhooks toward Workflows/Power Automate patterns.

Cost-effective choice:

Use Azure Monitor alerts + Action Group + Logic App only for production error conditions instead of continuously polling telemetry.
Trigger notifications only when the alert fires, which is generally more cost-efficient than scheduled query workflows that run every few minutes.

Answer 2

Hello Deepika

Thank you for posting your query on Microsoft Q&A platform.

Action Groups do not have a built‑in "Microsoft Teams" action type. The supported action types in an Action Group are Webhook, Azure Function, Logic App, Automation Runbook, ITSM, Secure Webhook, and Event Hubs, Teams isn't a native option here Create and manage action groups. So to land alerts in a Teams channel, you need to bridge through one of those action types.

Both of the following are Microsoft-supported and low/no-cost:

Option 1 – Webhook straight into a Teams Workflow (no Logic App needed, lowest cost)

In your target Teams channel, select → Workflows, and choose the template "Post to a channel when a webhook request is received" (built on the When a Teams webhook request is received trigger). This is the current, supported replacement for the old Incoming Webhook connector, which Microsoft has scheduled for retirement Create an Incoming Webhook, Send messages in Teams using incoming webhooks.
Save the workflow to get its webhook URL.
In Azure Monitor, create an Action Group with a Webhook action pointing to that URL, and enable "Use common alert schema." This is what standardizes the JSON payload so your workflow can parse it consistently. Common alert schema for Azure Monitor alerts.
1. Attach that Action Group to your exception alert rule.

For step 1, note this important detail from Microsoft's docs: these Teams "Post message/adaptive card" actions require the Workflows (Power Automate) app to be enabled and set to "allow" in the Teams admin center (Microsoft Teams connector reference).

Option 2 – Logic App with the native Teams connector (if you want to enrich the message, example pull extra query results, format a card, filter by exception type)

Create a Consumption Logic App with trigger "When a HTTP request is received."
Add the Microsoft Teams → "Post message in a chat or channel" (or "Post adaptive card in a chat or channel") action (Microsoft Teams connector reference).
Point your Action Group's Webhook (or the Logic App action type directly) to this Logic App, again with the common alert schema enabled.

Connecting the Teams action in a Logic App currently requires a user account connection — there's no managed identity / app-only auth path for this connector today, so plan for a service account if this needs to run unattended long-term.

To get the exception type, outerMessage, and timestamp into the message body, base your alert on a log search (scheduled query) alert rule against your exceptions table (e.g., project timestamp, type, outerMessage, method) rather than a metric alert — those fields come through as row data in the alert payload's search results.

For payloads over 256 KB, Azure Monitor automatically adds LinkToFilteredSearchResultsAPI fields you can call instead of relying on inline row data (Sample payloads for log search alerts using webhook actions). The alert essentials also include a portal investigation link you can surface as your "App Insights link."

Both approaches reuse your existing alert rule and action group infrastructure — you're just adding a second action group action (webhook) alongside your current SMS one, so nothing about your SMS alerting needs to change.

Hope that gets you unblocked.

I hope the details shared above helped in addressing your concern.

If the suggested resolution resolved the issue, kindly consider marking the answer as "Accepted" and "Upvote" it. This helps other community members who may encounter a similar issue in the future.

If you’re still experiencing the problem or need further clarification, please feel free to share additional information so we can continue investigating and assist you further.

Thanks,

Suchitra.