When the Azure Copilot Observability Agent detects a problem, correlates related alerts, investigates and creates an Azure Monitor issue, it does more than identify what happened. It creates a durable record that brings together investigation findings, severity, impacted resources, and recommended next steps in a single place.
In many organizations, however, understanding a problem is only part of the workflow. Teams still need to notify stakeholders, create tickets, start remediation processes, or coordinate work across multiple systems.
By connecting Azure Monitor issues to Logic Apps, Azure Functions, and other Azure services, triggered automatically via Action Groups, you can now provide the most relevant context to operational workflows across systems.
Building on the Azure Ecosystem
Azure Monitor issues carry enough context that the workflow on the other end can act without any manual input — the issue title, severity, investigation findings, and a direct link back to Azure Monitor are all there.
Azure Monitor provides a simplified integration with ServiceNow ITOM to keep Azure Monitor issues and ServiceNow incidents in sync. Beyond this purpose-built integration, Action Groups, Logic Apps, and Azure Functions enable a broader range of workflows, such as:
- Notify your on-call team in Teams when a Sev1 issue is created, with the investigation summary already included.
- Open an Azure DevOps work item for engineering follow-up and tracking.
- Route issues automatically based on severity, service ownership, or business impact.
- Trigger a remediation workflow when a known issue pattern is detected.
- Stream issue events to Event Hubs for operational analytics and trend analysis.
This flexibility allows you to incorporate Azure Monitor issues into the workflows you already rely on, while continuing to use the Azure services and tools that best fit your operational needs. The Observability Agent prepares the investigation context and findings; your configured workflows handle the downstream response — keeping humans in control of the decisions that follow.
Example 1: Bringing Issue Information into Microsoft Teams
Consider a production issue detected in Azure Monitor.
Through autonomous operations (public preview), the Observability Agent can run an automatic investigation, and create an Azure Monitor issue with findings and recommended next steps. Using these capabilities requires a configured Azure Copilot Observability Agent resource.
Action Groups are configured on the Azure Monitor Workspace (Azure Monitor issue actions) and can be triggered on issue creation or update. When associated with an issue, the action group can send issue information to existing workflows using services like Logic Apps, Azure Functions, or webhooks.
In this example, a Logic App workflow posts issue information to a Microsoft Teams channel, allowing engineers and operators to become aware of the problem without continuously monitoring dashboards.
The notification includes everything the workflow needs to surface to your team: the issue title, severity, status, and impact time; a summary with the Observability Agent’s investigation findings; and a direct link back to the full issue in Azure Monitor. If the Action Group fires on a change rather than issue creation, the payload also includes what changed.
The following example shows the main setup steps.
Step 1: Define the Logic App workflow
Step 2: Connect the Logic App workflow to an Action Group
The Action Group uses the Logic App action.
Step 3: Set the Action Group as a default action on the Azure Monitor Workspace
Step 4: Confirm notifications when creating an Observability Agent
Step 5: Receive the Teams notification
Example 2: Custom Workflows with Azure Functions
The same issue payload can also be processed by Azure Functions to support more advanced scenarios. Because Azure Monitor issues already contain rich operational context — including severity, status, impacted resources, investigation findings, and a link back to the issue — a function can inspect that information and automate the next step in the workflow.
This approach enables organizations to build workflows that go beyond notifications, such as enriching issue data, coordinating actions across systems, generating operational artifacts, or integrating with internal platforms and processes. The Azure Functions serverless agents runtime, currently in preview, supports these kinds of event-driven, agent-aware workflows.
Consider a platform operations team that supports multiple applications. When an issue is created, a serverless triage agent running in Azure Functions can inspect its context, identify the service owner through a configured tool, and create an Azure DevOps work item in the appropriate team queue.
The following example uses the Serverless Agents Runtime, where agent behavior and its HTTP trigger are defined in a single markdown file:
—
name: Azure Monitor Issue Triage
description: Routes Azure Monitor issues and prepares Azure DevOps work items.
trigger:
type: http_trigger
args:
route: issue-triage
auth_level: FUNCTION
—
You are an incident-triage agent. The request contains an Azure Monitor
issue payload.
1. Extract the available title, severity, status, impact time, impacted
resources, investigation findings, recommended next steps, and Issue URL.
2. Use the configured service-ownership tool to identify the owning team.
Never infer ownership from a resource name alone.
3. If one team is identified, route the Issue to that team’s Azure DevOps
project and area path. If ownership is missing or ambiguous, use the
Central Operations triage queue.
4. Create a concise work item containing:
– Customer or service impact
– Likely cause and supporting evidence
– Recommended next steps
– Severity and affected resources
– A link to the original Azure Monitor issue
5. Return the selected team, work-item ID, and routing reason.
Do not invent missing information, perform remediation, or change Azure
resources.
To Summarize
Azure Monitor issues bring together valuable, rich context, generated by the Observability Agent — correlated alerts, findings, evidence, and recommended next steps.
By configuring default Action Groups on the Azure Monitor Workspace where issues are stored, you can extend those findings into the tools and workflows your team relies on, so collaboration, ticketing, automation, and custom processing all start from the same investigated context. The Observability Agent is generally available in Azure Monitor; autonomous operations, which create and update issues automatically, are available in public preview. The agent prepares and updates the issue; humans stay in control of the decisions and actions that follow.
Next Steps
- Azure Copilot Observability Agent overview — get started with the Observability Agent and understand how autonomous operations work.
- Azure Monitor issue actions — learn what an issue contains, when actions run, and which action types are supported.
- Action Groups in Azure Monitor — configure notifications and automated workflows.
Stay connected
- Follow this blog for ongoing deep dives, updates on current capabilities, and a preview of what’s coming next.
- Live webinar — a walkthrough of real Observability Agent scenarios, best practices, and what’s available today, along with a look at what’s coming next, and live Q&A with the product team. Register for the Observability Agent webinar
We’d love your feedback
The Observability Agent continues to evolve based on real-world usage and operator feedback. Share your thoughts directly through the Give Feedback option in the experience, or reach us at azureobsagent@microsoft.com.