When an Azure Monitor alert β or a ServiceNow or Zendesk ticket β fires into JAMS Incident Management, it creates an incident: a tracked row you can acknowledge and resolve/close from one place, with the state syncing back to the source system. The Incidents page is where your team manages those alerts after they arrive.
Plan availability: Incidents come from the two-way integrations β Azure Monitor, ServiceNow, and Zendesk. See each integration's article (and Plans & Billing) for its plan requirements.
This page is admin-only. Tenant admins see it; regular team members don't.
Why this matters: Acknowledging or closing an incident here isn't just a local note β JAMS pushes the change back to Azure Monitor's alert state. The incident list and the Azure Portal stay in sync, so you don't have to update the alert in two places.
What the page shows
Incidents lists every incident for your tenant β from Azure Monitor, ServiceNow, and Zendesk. Each row shows the alert/ticket name, severity, the flow that handled it, when it triggered, and its current state. You can filter by status, severity, and flow.
Incidents move through three states:
| State | What it means |
|---|---|
| New | The alert fired and hasn't been acknowledged yet. Notifications are still escalating. |
| Acknowledged | Someone has taken ownership. Escalation stops; the incident is being worked. |
| Closed | The issue is resolved. Both JAMS and Azure Monitor consider the alert closed. |
Note: "Closed" is Azure Monitor's term, so that's what the page shows. Under the hood JAMS stores this state as
resolvedβ same thing, just the label matches the Azure Portal.
Source differences: ServiceNow and Zendesk tickets surface here too, and the final-state action matches the source β Azure Monitor Close, ServiceNow Resolve, Zendesk Solve β syncing back to that system. Acknowledge works the same for all three. See ServiceNow and Zendesk.
Acknowledging an incident
Click Acknowledge on a New incident.
- JAMS PATCHes the alert's state to Acknowledged in Azure Monitor.
- The matching JAMS incident flips to Acknowledged.
- Any in-flight escalation for that alert stops β the rest of the rotation won't get paged.
Acknowledge says "I've got this." It doesn't close the alert; it just stops the paging while someone investigates.
A recipient can also acknowledge straight from the notification itself β pressing a key on the voice call, replying to the SMS, tapping the push, or clicking the email link. However it's acknowledged, the state syncs the same way. See Voice acknowledgement for what a recipient hears on a call.
Closing an incident
Click Close once the underlying problem is fixed.
- JAMS PATCHes the alert's state to Closed in Azure Monitor.
- The JAMS incident moves to Closed.
- Any pending notifications for the alert are cancelled.
Closing is the end state β it tells both JAMS and Azure Monitor the alert is done.
Force close: for orphan incidents only
Sometimes the Azure alert behind an incident no longer exists β it was deleted, it expired, or the incident came from the Azure Portal's test-webhook button. When that happens, the normal Close button fails: Azure returns a 404 because there's nothing left to update, and the incident stays stuck.
Force close is the escape hatch for exactly this case.
- Click Force close on the stuck incident.
- Confirm the prompt β force close is deliberate, so it asks first.
- JAMS marks the incident closed and cancels its pending notifications without contacting Azure Monitor.
Because force close skips the Azure PATCH entirely, only use it for orphan incidents that no longer exist in Azure. For a live alert, use the normal Close button so Azure stays in sync.
Why this matters: Force close is the only action on this page that doesn't touch Azure Monitor. If you force-close a live alert, JAMS will think it's done but Azure Monitor will still show it open. Reserve it for alerts that are genuinely gone from Azure.
Setting up the integration
Incidents only appear once Azure Monitor is sending alerts to JAMS. To wire that up β connecting an Azure Monitor alert rule, granting the role JAMS needs to write state back, and pointing the webhook at a flow β see Azure Monitor integration.