← Back to Dashboard
JAMSHelp Center

Azure Monitor (Two-Way)

Azure Monitor sends incident webhooks to JAMS Incident Management, and JAMS Incident Management calls, SMS-es, emails, or messages (push / Teams / Slack) your on-call team. When someone Acknowledges or Closes, JAMS Incident Management PATCHes the alert state back into Azure — so your dashboard, post-incident review, and Azure-side automation all see the resolution without anyone double-bookkeeping.

Plan availability: The Azure Monitor integration is included on the Professional plan and up. See Plans & Billing.

Where to set it up: manage the Azure Monitor connection from /integrations/azure-monitor, or start from New Alert Flow (/flows/new) → the Azure Monitor source (shown when your plan includes it), which opens the same form. After you save, click View Flows to see the managed flow in your Flows list — where Edit returns you to this form and Delete removes the connection and its flow together.

What you'll get

After setup:

  • An Azure Monitor alert fires → action group calls JAMS Incident Management's webhook → recipients get a call (and/or SMS / email / push / Teams / Slack per your flow)
  • Recipients press 1 to Acknowledge or 2 to Close — or do nothing and reminders keep coming
  • Acknowledge sets the Azure alert to Acknowledged; Close sets it to Closed
  • If Azure auto-resolves the alert (the condition went back to normal), JAMS Incident Management stops calling and marks the incident resolved
  • The /incidents page shows everything in flight with one-click Acknowledge / Close buttons

What you'll need

  1. An Azure subscription with at least one resource you want to monitor.
  2. A JAMS Incident Management flow configured to fire on the Azure Monitor trigger (any flow that's active will do; the webhook URL is per-flow).
  3. Monitoring Contributor role granted to the JAMS Incident Management backend's managed identity on the Azure subscription (one-time, see below). Without this, JAMS Incident Management can deliver alerts to your team, but cannot push Acknowledge / Close back to Azure.

Step 1 — Grant JAMS Incident Management's managed identity Monitoring Contributor

The JAMS Incident Management backend runs under a managed identity that calls the Azure Alerts Management REST API to push Acknowledge / Close back into Azure. To let it update your alerts, you grant that identity the Monitoring Contributor role on your Azure subscription.

You are not adding an App Service to your tenant. You're picking JAMS Incident Management's existing managed identity (it lives in our tenant) as the member of a role assignment in yours. Do this once per subscription whose alerts you scope into a flow.

  1. In the Azure Portal, open the Subscription that contains your alert rules.
  2. Go to Access control (IAM) → Add → Add role assignment.
  3. Role: search for Monitoring Contributor and select it.
  4. Members:
    • Assign access to: Managed identity.
    • Click + Select members. Search for the managed identity name shown on JAMS Incident Management's /integrations/azure-monitor setup page — that page displays the exact identity to grant. Select it.
  5. Review + assign.

Why this matters: the grant is per-subscription. If your alert rules span several subscriptions, repeat Steps 1–5 for each one — otherwise Acknowledge / Close will work for alerts in the granted subscription and fail for the others.

It can take a minute for role propagation. If the first Acknowledge fails with "Our identity is not authorized to update this alert", wait a moment and retry.

Step 2 — Get the webhook URL from JAMS Incident Management

Each flow has its own webhook URL so a single tenant can route different alerts through different escalation policies.

  1. In JAMS Incident Management, open the Flow you want Azure Monitor to trigger.
  2. Open the Trigger section. Pick Azure Monitor.
  3. Copy the webhook URL — it looks like https://<your-JAMS-backend-host>/api/azure-monitor/webhook/{tenantId}/{flowId}. The real host is filled in for you on the page; copy the value as shown rather than typing it.

Step 3 — Create the Azure Monitor action group

The action group is what Azure uses to deliver the webhook payload.

  1. In the Azure Portal, go to Monitor → Alerts → Action groups → Create.
  2. Basics: name it something obvious (e.g. jams-oncall). Pick the resource group where you'll create your alert rule.
  3. Notifications: skip — JAMS Incident Management handles delivery to people.
  4. Actions: add an Action of type Webhook.
    • Name: jams-webhook
    • URI: paste the URL from Step 2.
    • Enable the common alert schema: YES. This is required — JAMS Incident Management parses the v1 common schema only. (If the toggle isn't there, your portal default is already common-schema; verify by checking the Test webhook payload.)
  5. Save.

Test it now. From the action group page, Test → Webhook → Storage account / VM / Generic alert. Pick any sample, click Test. You should get a JAMS Incident Management call/SMS within ~10 seconds and an entry under /incidents.

Step 4 — Attach the action group to an alert rule

  1. Monitor → Alerts → Alert rules → Create.
  2. Pick your Resource scope (a VM, App Service, database — anything with metrics).
  3. Condition: for first-time testing, Metric alert — Static, pick any metric (CPU, request count), set the threshold to something you can easily breach. We're just confirming end-to-end delivery.
  4. Actions: Select action groups → pick the one from Step 3.
  5. Details: name the rule, severity defaults to Sev 3 — bump to Sev 2 for testing if you want a more urgent voice prompt.
  6. Save the rule.

How the two-way flow works

Azure Monitor alert fires
   │
   ▼
Action group POST → /api/azure-monitor/webhook/<tenant>/<flow>
   │
   ▼
JAMS Incident Management creates Incident + fires flow notifications (call, SMS, email, push, Teams, Slack)
   │
   ▼ recipient presses 1 / 2 (or clicks button on /incidents)
   │
   ▼
JAMS Incident Management PATCHes /subscriptions/<sub>/providers/Microsoft.AlertsManagement
                  /alerts/<alertId>/changestate?newState=Acknowledged|Closed
   │
   ▼
Azure portal + downstream automation see the new state
JAMS Incident Management's escalation stops (notifications cascade to "acknowledged")

Voice-call menu

When the call lands, after the alert summary you'll hear:

"Press 1 or say acknowledge to acknowledge. Press 2 or say close to close."

  • 1 / "acknowledge" → Azure alert → Acknowledged. JAMS Incident Management keeps a reminder cadence going (default every 30 min) until somebody closes it — see "Reminder behavior" below.
  • 2 / "close" → Azure alert → Closed. JAMS Incident Management marks the incident resolved. No more reminders. (Speech recognition also accepts "resolve" / "resolved" here, but the prompt advertises "close".)

You can also press 3 to replay the message at any time.

SMS replies

Reply to the alert SMS with 1 for Acknowledge or 2 for Close. JAMS Incident Management confirms with a short reply ("Acknowledge submitted. Thanks." or "Close submitted. Thanks."). Same Azure-side effect as the voice menu.

/incidents page

Open /incidents. New incidents show Acknowledge and Close buttons; acknowledged incidents show only Close. Buttons hit the same backend code as the voice/SMS path — Azure stays in sync.

Auto-resolve

If Azure Monitor resolves the alert on its own (the metric dropped back under the threshold, etc.), Azure POSTs a follow-up webhook with monitorCondition: Resolved. JAMS Incident Management:

  1. Marks the incident resolved.
  2. Cancels any queued/sent notifications in the same group (no more pages for an alert that's no longer firing).
  3. Logs azmon.auto_resolved in the audit trail.

You don't need to do anything for this to work — it's the default behavior.

Force-close (orphan incidents only)

Sometimes an incident gets stuck because the alert behind it no longer exists in Azure — it was deleted, expired, or it came from the Test webhook sample (which uses the placeholder subscription 11111111-1111-1111-1111-111111111111). A normal Close would try to PATCH Azure and fail with "Azure no longer has this alert," leaving the incident sitting in your list.

For exactly these cases, the /incidents page has a Force close button (separate from the regular Close):

  1. Open /incidents and find the stuck incident.
  2. Click Force close (skip Azure) and confirm.

Force-close marks the incident resolved on the JAMS Incident Management side and cancels any pending notifications, but it deliberately does not PATCH Azure — there's nothing in Azure to update. It's logged as a manual override (azmon.force_closed) in the audit trail so it's distinguishable from a normal Azure-mirrored close.

Use it only for orphans. For a live alert that still exists in Azure, use the regular Close so the state syncs back. Force-close is the escape hatch for incidents Azure can no longer match. See Incidents for the full incident lifecycle.

Reminder behavior

When an incident is acknowledged but not yet closed, JAMS Incident Management's default is:

  • Keep pinging the same on-call rotation every 30 minutes with a "still open" reminder.
  • The reminder body says "is acknowledged but still open" instead of "URGENT" so the recipient knows it's a nudge, not a new alert.

Per-flow knobs (Flow settings → Incident reminders):

  • Remind after Acknowledge: true (default) — keep nudging. false — go silent after Ack; the next call/SMS only comes if Azure re-fires or someone re-opens.
  • Ack reminder interval: 30 minutes by default. Set it shorter for critical flows; longer for low-severity ones.

The pre-Ack reminder cadence is still controlled by the existing flow cooldownMinutes.

Verify it works (end-to-end)

After Step 4 you should be able to:

  1. Wait for the alert rule's first eval (1-5 min after Save).
  2. Force the metric to breach (stress the resource, or use a synthetic — for App Services, an HTTP 500 alert fires fast if you hit /this-route-does-not-exist).
  3. Within ~10s of the alert firing, the on-call recipient should get a JAMS Incident Management call / SMS.
  4. Press 1 on the call (or reply 1 to the SMS).
  5. In the Azure Portal, open Monitor → Alerts → All alerts. The alert state should flip to Acknowledged within a few seconds.
  6. Press 2 (or reply 2) — the state flips to Closed.

Troubleshooting

SymptomLikely causeFix
JAMS Incident Management never callsAction group webhook URL wrong, or common alert schema disabledRe-copy the URL from your flow. Confirm the common-schema toggle is ON. Use Test webhook from the action group page.
Calls land, but pressing 1 says "Acknowledge failed. Our identity is not authorized to update this alert."JAMS Incident Management's managed identity is missing Monitoring Contributor on this subscriptionRepeat Step 1 for the subscription the alert lives in. Wait ~1 min for role propagation.
Pressing 1 says "Acknowledge failed. Could not authenticate with Azure."Backend-side Azure auth problemThis is on the JAMS Incident Management side, not yours — contact support with the time of the failed call.
Pressing 1 says "Acknowledge failed. Azure no longer has this alert."Azure already closed the alert (auto-resolved); the action arrived lateHarmless — the incident is already resolved on JAMS Incident Management's side. Check /incidents to confirm.
/incidents shows the right alerts but pressing the button hangsBackend reached the incident but couldn't reach Azure to PATCH the stateUsually transient — retry. If it persists, contact support with the incident name and the time you clicked.
Reminders keep coming after you AcknowledgedReminder-after-Ack is ON (default) for the flowEither Close the incident, or flip the flow's Remind after Acknowledge off in Flow settings.

If you hit something not on this list, capture the time of the failed call/SMS and a screenshot of the /incidents audit log, then reach out to support — that gives us enough to trace through the backend's [Azure Monitor] log lines.