Azure Monitor Alerts
- Connect Azure Monitor in Builder → Incident platform — your agent's managed identity handles authentication, no API keys or credentials needed
- Scanner detects new alerts every minute, acknowledges them in Azure Monitor, and creates investigation threads
- Recurring alerts from the same rule merge into one thread within a configurable cooldown window (default 3 hours) — five firings become one investigation, not five
- Incident response plans control which severity levels your agent handles and whether it acts autonomously or waits for approval
The problem: manual alert management doesn't scale
When an Azure Monitor alert fires, you open Azure Portal to read the alert details. Then you switch to Log Analytics to check for errors. Then Application Insights for exceptions. Then deployment history to see if someone pushed a change. Each tool switch costs time and breaks your focus.
Noisy alerts make it worse. A CPU threshold breached every five minutes generates a new alert each time — and each one sits in your queue demanding separate acknowledgment, triage, and investigation. By morning, you've acknowledged the same underlying problem twelve times with no consolidated view of what happened. The signal is buried under duplicate noise.
How Azure Monitor integration works
Your agent connects to Azure Monitor through its managed identity — the same identity it uses to access your Azure resources. No API keys, no OAuth flows, no credential rotation.
- Your agent must be in Running state
- The agent's managed identity needs Monitoring Contributor role on the subscriptions containing your alert rules — assigned automatically when you add managed resource groups during agent creation, or when you connect Azure Monitor as your incident platform
- Managed resource groups determine which subscriptions the agent scans — the agent monitors all Azure Monitor alerts across each subscription that contains a managed resource group
Navigate to Builder → Incident platform, select Azure Monitor from the dropdown, and save.
After saving, your agent begins scanning for alerts across the subscriptions that contain your managed resource groups. A default incident response plan is created that handles Sev3 alerts in autonomous mode. You can create additional response plans for other severity levels.
Your agent connects to one incident platform at a time. To switch from PagerDuty or ServiceNow to Azure Monitor, disconnect the current platform first.
Alert detection and acknowledgment
The scanner polls Azure Monitor every minute for new alerts. When it finds an alert with state "New" and condition "Fired":
- Acknowledges the alert in Azure Monitor — changing its state from New to Acknowledged so other tools know it's being handled
- Checks for existing investigations — if an active thread already exists for the same alert rule, the alert merges into that thread instead of creating a new one
- Creates an investigation thread (for new alerts only) with a severity-prefixed title (for example, [Sev2] CPU Alert)
- Begins investigating using all your connected data sources — correlating logs, metrics, and deployment history
Recurring alert merging
When the same alert rule fires again while an investigation already exists, the agent can merge the new alert into the existing thread instead of starting a new investigation. This behavior is controlled per response plan.
| Setting | Default | Range |
|---|---|---|
| Merge recurring alerts | Enabled | On / Off |
| Cooldown time | 3 hours | 1–24 hours |
When merge is enabled (default):
- If an active thread exists for the same alert rule within the cooldown window, the new alert merges silently — the total alert count increments and the latest fire time updates, but no new investigation starts
- If the previous thread was resolved or closed within the cooldown window, the agent reopens it instead of creating a new thread
- If no thread exists within the cooldown window, a new investigation thread is created
Five firings of the same alert rule within the cooldown window produce one investigation thread with Total alerts: 5 — not five separate threads investigating the same problem.
When merge is disabled:
- Every alert fire creates a new investigation thread, even from the same rule
Disabling merge means every fire of a noisy alert rule triggers a new investigation. For rules that fire frequently (CPU or memory threshold alerts), this can significantly increase token consumption.
Status sync
A background process checks Azure Monitor every 2 minutes for status changes. When an alert transitions to resolved or closed, the agent generates an AI root cause summary for the investigation thread.
Thread titles preserve their severity prefix through status transitions — [Sev2] CPU Alert stays [Sev2] CPU Alert.
The agent tracks whether each incident was mitigated by agent or mitigated by user. These counts appear in the incident analytics dashboard and in per-response-plan breakdowns, so you can measure how much investigation work the agent handles autonomously.
Historical incident metrics
A background service automatically syncs historical alert data from Azure Monitor into your incident analytics dashboard. This sync covers alerts from the past 29 days and runs incrementally — after the initial backfill, only new or updated alerts are fetched.
The synced data powers all charts and KPI cards on the Monitor → Incident metrics page, including trend lines, response plan breakdowns, and the Overview "Daily Activity" chart. No additional configuration is needed — the sync starts automatically when Azure Monitor is connected as your incident platform.
What's supported
| Feature | How it works |
|---|---|
| Zero-credential setup | Agent's managed identity handles authentication — select the platform, save, and alerts start flowing |
| Automatic acknowledgment | Agent acknowledges alerts in Azure Monitor the moment it creates an investigation thread |
| Recurring alert merging | Same alert rule fires merge into one thread within a configurable cooldown window (default 3 hours) |
| Resolved thread reopening | If a resolved thread is within the cooldown window, the agent reopens it instead of creating a new thread |
| AI root cause summary | Generated automatically when an alert resolves |
| Mitigation tracking | Analytics show mitigated by agent vs mitigated by user |
| Historical incident metrics | Background sync backfills up to 29 days of alert history into the incident analytics dashboard |
Viewing alerts in the incident list
The incident list includes two columns specific to Azure Monitor:
- Total alerts — the number of times the same alert rule has fired for this investigation, clickable to view details
- Last fired — when the most recent alert for this rule occurred
Click any Total alerts count to open a dialog showing every alert instance:
| Column | What it shows |
|---|---|
| Alert id | The alert GUID with a copy button |
| Fired at | When this specific alert instance fired |
| Alert status | Current status (New, Acknowledged, Resolved) |
| Alert condition | Whether the alert condition is Fired or Resolved |
| Azure Monitor | Link to view the alert in Azure Portal |
Controlling which alerts your agent handles
Incident response plans define which alerts your agent investigates and how much autonomy it has. Navigate to Builder → Incident response plans to create or modify plans.
Each plan specifies:
- Severity levels — which Azure Monitor severities to match (Sev0 through Sev4)
- Title pattern — filter alerts by title content (include or exclude specific keywords)
- Autonomy level — Autonomous (agent acts independently) or Manual (agent proposes, you approve)
- Custom response plan — route alerts to a specific custom agent for specialized response
Response plans also support custom investigation instructions and trigger event configuration. See Incident Response Plans for full details.
The default response plan created during setup handles Sev3 alerts in Autonomous mode. To handle other severity levels, create additional response plans.
Azure Monitor severity mapping
| Azure Monitor Severity | Description |
|---|---|
| Sev0 | Critical |
| Sev1 | Error |
| Sev2 | Warning |
| Sev3 | Informational |
| Sev4 | Verbose |
Scanner behavior
| Setting | Value |
|---|---|
| Scan interval | 1 minute |
| Alerts per API call | 250 |
| Initial scan lookback | 1 day |
| Maximum scan window | 29 days |
| Merge lookback | 7 days (active threads from same alert rule) |
| Status sync interval | 2 minutes |
If alerts don't appear after connecting, verify:
- The agent's managed identity has Monitoring Contributor role on the subscription
- Azure Monitor alert rules exist on resources in your managed resource groups
- Alert rules have actually fired (check Azure Monitor → Alerts in Azure Portal)
Get started
Connect Azure Monitor by navigating to Builder → Incident platform, selecting Azure Monitor, and saving. Alerts from your managed resource groups begin flowing within 1–2 minutes.
| Resource | What you'll learn |
|---|---|
| Automate Incident Response → | End-to-end setup including managed resource groups and response plans |
Related capabilities
| Capability | What it adds |
|---|---|
| Incident Response → | How your agent investigates and responds to all incident types |
| Incident Response Plans → | Control which alerts your agent handles with severity routing and autonomy levels |
| Root Cause Analysis → | AI-driven hypothesis formation and evidence validation |
| Azure Observability → | Built-in Azure diagnostic tools for investigation |
| Track Incident Value → | Measure alert resolution trends, mitigation rates, and response plan performance over time |