Azure Monitor (Two-Way)

Azure Monitor sends incident webhooks to JAMS IMES, and JAMS IMES calls / SMS-es / emails your on-call team. When someone Acknowledges or Closes, JAMS IMES 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.

What you'll get

After setup:

• An Azure Monitor alert fires → action group calls JAMS IMES's webhook → recipients get a call (and/or SMS/email 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 IMES 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 IMES 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 IMES backend's managed identity on the Azure subscription (one-time, see below). Without this, JAMS IMES can deliver alerts to your team, but cannot push Acknowledge / Close back to Azure.

---

Step 1 — Grant JAMS IMES's managed identity Monitoring Contributor

JAMS IMES's backend App Service uses a system-assigned managed identity to call the Azure Alerts Management REST API. You only need to do this once per subscription.

1. In the Azure Portal, open the Subscription that contains your alert rules.
2. Go to Access control (IAM) → Add role assignment.
3. Role: search for Monitoring Contributor and select it.
4. Members: assign to a Managed identity. Pick the subscription where JAMS IMES is hosted, then User-assigned managed identity is wrong — choose App Service and pick notiphone.
5. Review + assign.

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 IMES

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

1. In JAMS IMES, 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://notiphone-.../api/azure-monitor/webhook/{tenantId}/{flowId}.

---

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. notiphone-oncall). Pick the resource group where you'll create your alert rule.
3. Notifications: skip — JAMS IMES handles delivery to people.
4. Actions: add an Action of type Webhook.
   • Name: notiphone
   • URI: paste the URL from Step 2.
   • Enable the common alert schema: YES. This is required — JAMS IMES 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 IMES 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 IMES creates Incident + fires flow notifications (call, SMS, email)
   │
   ▼ recipient presses 1 / 2 (or clicks button on /incidents)
   │
   ▼
JAMS IMES PATCHes /subscriptions/<sub>/providers/Microsoft.AlertsManagement
                  /alerts/<alertId>/changestate?newState=Acknowledged|Closed
   │
   ▼
Azure portal + downstream automation see the new state
JAMS IMES'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 IMES keeps a reminder cadence going (default every 30 min) until somebody closes it — see "Reminder behavior" below.
• 2 / "close" / "resolve" → Azure alert → Closed. JAMS IMES marks the incident resolved. No more reminders.

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 IMES 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 IMES:

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.

---

Reminder behavior

When an incident is acknowledged but not yet closed, JAMS IMES'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 IMES 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

Symptom	Likely cause	Fix
JAMS IMES never calls	Action group webhook URL wrong, or common alert schema disabled	Re-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."	Managed identity missing Monitoring Contributor	Repeat Step 1. Wait ~1 min for role propagation.
Pressing 1 says "Acknowledge failed. Could not authenticate with Azure."	Managed identity not enabled on the App Service	In the Azure Portal → notiphone App Service → Identity → System-assigned → On
Pressing 1 says "Acknowledge failed. Azure no longer has this alert."	Azure already closed the alert (auto-resolved); the action arrived late	Harmless — the incident is already resolved on JAMS IMES's side. Check /incidents to confirm.
/incidents shows the right alerts but pressing the button hangs	Backend can reach JAMS IMES but not Azure	Check App Service outbound networking; the App Service must be able to reach https://management.azure.com. No VNet integration is required by default.
Reminders keep coming after you Acknowledged	Reminder-after-Ack is ON (default) for the flow	Either 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.