Microsoft published a new integration pattern on August 16, 2026 that connects Azure Monitor issues with ServiceNow IT Operations Management.

When Azure Monitor creates an issue, a secure webhook can send it to ServiceNow ITOM as an alert. ServiceNow can create an incident in ITSM or another connected ticketing system, retrieve related Azure alerts and resources, and synchronize status changes back to Azure Monitor.

The goal is not to replace either platform. Azure Monitor remains the technical investigation workspace, while ServiceNow manages assignment, escalation, service levels, communications, and incident closure.

An Issue Is More Than One Alert

An Azure Monitor issue brings related operational evidence into a shared technical workspace.

It can contain issue metadata, affected resources, related alerts, and investigation results produced by the Azure Copilot Observability Agent. Responders can use that context to understand the service degradation, refine the investigation, and coordinate mitigation.

An issue can be created from a saved investigation. It can also be created by the Observability Agent's autonomous operations capability, which is currently in public preview.

ServiceNow solves a different part of the response.

The ServiceNow incident is the operational record used for ownership, priority, escalation, communications, service-level tracking, and closure. Connecting the two records lets engineers work from the Azure evidence while service-management teams keep using their governed incident process.

Without the integration, responders copy details manually, links drift, and one system often closes while the other remains open.

Issue Actions Provide the Connection Point

Azure Monitor issues use the action-groups model already familiar from Azure Monitor alerts.

When an issue is created or updated, Azure Monitor triggers the default action groups configured on the Azure Monitor Workspace that stores it.

An action group can use:

• Email, SMS, or voice

• Logic Apps

• Azure Functions

• Event Hubs

• Automation Runbooks

• Webhooks or secure webhooks

That means ServiceNow is not the only possible destination. Teams can transform, route, enrich, or fan out issue data through their existing automation architecture.

The ServiceNow ITOM path adds a purpose-built connection that links the Azure issue, its alerts and resources, the ITOM alert, and the resulting incident.

The End-to-End ServiceNow Flow

The integration uses Azure Monitor actions plus ServiceNow push and pull connectors.

The operational sequence is:

• Azure Monitor creates an issue from a saved investigation or autonomous operation.

• The Azure Monitor Workspace triggers its default action group.

• A secure webhook sends the issue to the inbound endpoint of the ServiceNow ITOM instance.

• The ServiceNow Azure Monitor push connector receives the issue and creates an ITOM alert.

• The ServiceNow pull connector retrieves the related Azure alerts and affected resources.

• ServiceNow creates an incident in ITSM or another ticketing system connected to ITOM.

• Responders work through linked records during investigation and response.

The push connector alone is not enough for complete context. It moves issues and alerts from Azure Monitor into ServiceNow. The pull connector is required to retrieve the issue's related alerts and resources.

When bidirectional synchronization is enabled on the pull connector, ServiceNow can update Azure Monitor as incidents and alerts close.

Secure Webhooks Protect the Inbound Path

Microsoft recommends a secure webhook action in the Azure Monitor action group.

Secure webhooks use Microsoft Entra ID authentication to protect delivery to the ServiceNow endpoint. If an existing action group already sends Azure Monitor alerts to ServiceNow ITOM through a secure webhook, the same action group can also be used for issues.

The integration still needs a full trust review.

Document:

• Which Entra application protects the ServiceNow endpoint

• Which tenant and audience are expected

• How credentials and certificates are rotated

• Which Azure Monitor Workspaces can trigger the action group

• Which ServiceNow instance and connector receive the payload

• Which users can view linked issue and incident data

• Where delivery failures and rejected requests are logged

A protected transport does not decide whether the recipient should receive every field. Review the payload for resource names, topology, alert details, subscription identifiers, and potentially sensitive operational context.

Configure Both Sides Deliberately

The high-level setup has three parts.

First, create or reuse an Azure Monitor action group and add a secure webhook that targets the ServiceNow ITOM inbound endpoint.

Second, assign that action group as a default action group on the Azure Monitor Workspace that stores the issues.

Third, configure the Azure Monitor push and pull connectors in ServiceNow. Enable bidirectional synchronization on the pull connector if ServiceNow closure should update Azure Monitor.

Then test two separate outcomes:

• Creation and context: the ITOM alert, incident, related alerts, related resources, and Azure Monitor issue link all appear.

• Lifecycle synchronization: closing the test incident and alert produces the intended status changes in Azure Monitor.

Do not treat successful ticket creation as proof that the integration is complete. Missing related resources, failed pull permissions, broken links, or one-way closure can still leave responders with fragmented context.

Define Which System Owns Each Field

Bidirectional synchronization creates an ownership decision.

Azure Monitor is usually authoritative for technical state such as affected resources and alert resolution. ServiceNow is usually authoritative for assignment, business priority, communications, and service-management closure.

Create a field-level contract for:

• Severity and priority

• Status and closure reason

• Assignment group

• Affected service or configuration item

• Related alerts and resources

• Investigation link

• Incident notes

• Timestamps

• Correlation identifiers

Avoid designing two systems that can continuously overwrite the same value. Define allowed state transitions and the result when updates arrive out of order.

For example, decide whether closing a ServiceNow incident should always close the Azure issue or only when all related Azure alerts are resolved. A human service-management decision and a technical recovery signal are related, but they are not automatically identical.

Investigation Results Do Not Yet Synchronize

The Azure Monitor issue can include investigation results created by the Observability Agent.

Microsoft states that those investigation results are not synchronized into ServiceNow in the current integration. Adding them to the ServiceNow context is planned for a future iteration.

Responders can open the linked Azure Monitor issue from the ServiceNow Service Operations Workspace and continue the technical investigation in Azure Portal.

Build runbooks around the current boundary. Do not assume the ITSM incident contains the agent's evidence, hypotheses, or investigation output simply because the issue link is present.

Treat future synchronization as roadmap direction, not current functionality.

Engineer for Idempotency and Delivery Failure

Action groups, webhooks, connectors, and ticket automation operate across two platforms and a network boundary.

The design must tolerate retries without creating duplicate ITOM alerts or incidents.

Use the Azure issue identifier as the correlation key and preserve it through every record. Validate how ServiceNow behaves when the same creation payload is delivered more than once, when an update arrives before the pull connector completes, or when the connector is unavailable for an extended period.

Monitor:

• Action-group execution failures

• Secure-webhook authentication failures

• Delivery latency

• Connector backlog

• Duplicate alert or incident creation

• Pull-connector permission errors

• Failed status synchronization

• Records that remain open after the related system closes

Create reconciliation reporting that finds Azure issues without ServiceNow records and ServiceNow incidents whose Azure link no longer resolves.

Operational Governance Still Matters

Automation can make a weak incident process move faster without making it more correct.

Define which Azure Monitor Workspaces use the integration, which issue severities create incidents, how assignment is determined, who can close each record, and when human approval is required.

Review license, connector, and ServiceNow plugin requirements before production rollout. Test development or sub-production ServiceNow instances separately from the production incident queue.

Keep a manual fallback. During a ServiceNow or connector outage, responders still need a documented way to manage the Azure issue, notify the on-call team, and preserve the incident timeline.

Who Should Care?

Site reliability engineers should care because Azure investigation context can remain linked to the governed incident record.

ServiceNow and ITSM teams should care because assignment, escalation, service levels, and closure can stay in their established workspace.

Azure Monitor teams should care because issue actions and workspace-level action groups become part of the incident integration architecture.

Security teams should care because secure webhooks, connector identities, payload contents, and cross-platform links form a new trust boundary.

Operations leaders should care because bidirectional synchronization can reduce duplicate updates and status drift only when field ownership and closure semantics are explicit.

Practical Cloud Engineer Takeaway

Start with one non-production Azure Monitor Workspace and one ServiceNow test instance.

Create an action group with a secure webhook, assign it as the workspace's default action group, and configure both the push and pull connectors.

Run a controlled lifecycle test:

• Create an Azure Monitor issue.

• Verify one ITOM alert and one incident are created.

• Confirm related alerts and resources appear.

• Open the Azure issue from ServiceNow.

• Change severity and status in Azure and observe the ServiceNow records.

• Close the ServiceNow incident and alert.

• Confirm the expected Azure Monitor status updates.

• Repeat a delivery to validate idempotency.

• Disable a connector briefly and validate recovery and reconciliation.

Record every field mapping and state transition. Do not promote the workflow until the team can explain which system owns each value and how a failed update is detected and repaired.

Bottom Line

Azure Monitor issues can now participate in a connected ServiceNow ITOM incident workflow.

An Azure Monitor Workspace triggers a default action group, a secure webhook sends the issue to a ServiceNow push connector, and a pull connector retrieves related alerts and resources. With bidirectional synchronization enabled, ServiceNow closures can update Azure Monitor.

The integration lets technical responders investigate in Azure while service-management teams govern the broader incident in ServiceNow.

The right next step is a non-production lifecycle test that proves secure delivery, context retrieval, idempotency, field ownership, closure behavior, connector recovery, and reconciliation before the workflow reaches the production incident queue.

Sources

Microsoft Azure Observability Blog, published August 16, 2026: https://techcommunity.microsoft.com/t5/azure-observability-blog/keep-azure-monitor-issues-and-servicenow-itom-incidents-in-sync/ba-p/4543399

Azure Monitor issue actions: https://learn.microsoft.com/azure/azure-monitor/aiops/issues-overview#issue-actions

Connect ServiceNow to Azure Monitor with secure webhooks: https://learn.microsoft.com/azure/azure-monitor/alerts/itsmc-secure-webhook-connections-servicenow

Azure Monitor issues overview: https://learn.microsoft.com/azure/azure-monitor/aiops/issues-overview

ServiceNow Azure Monitor issue integration: https://www.servicenow.com/docs/r/it-operations-management/event-management/azure-monitor-issue-integration.html

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz