Webhook adapters

Azure Monitor

Send Azure Monitor alerts to WarnFire — a firing alert opens an incident and its resolution closes it.

If you run on Microsoft Azure and watch it with Azure Monitor alerts, this page connects them to WarnFire so a firing alert opens an incident and pages your on-call responder — and a resolution closes it automatically.

Alerts, not logs. WarnFire consumes Azure Monitor alerts — a metric, log, or activity-log alert rule that changes state. It does not read your raw log or metric streams. Set up the alert rules that matter, and WarnFire pages on those.

Azure delivers alerts through an action group with a Webhook action. You reuse one action group across as many alert rules as you like.

Before you begin

• A WarnFire service and integration key for these alerts. If you do not have one, create the service and its first key .
• Permission in Azure to create an action group and attach it to alert rules.

Your WarnFire address

Azure’s webhook action can’t attach a security header, so your integration key is part of the address itself:

https://api.warnfire.com/v1/integrations/webhooks/azure/wf_live_your_integration_key_here

Treat that whole address as a secret — anyone who has it can open incidents on your service. If it’s ever exposed, revoke the key under Services and use a fresh one.

Connect Azure Monitor to WarnFire

1. In the Azure portal, open Monitor → Alerts → Action groups and create an action group (for example, warnfire).
2. Under Actions, add an action of type Webhook:
   • URI: your WarnFire address from above.
   • Turn Enable the common alert schema on. WarnFire relies on this shared format — leave it off and alerts won’t map.
3. Save the action group.
4. On each alert rule that should page, add the warnfire action group under Actions.

How your alerts become incidents

WarnFire turns each Azure alert into one incident, using the alert’s identity so its states stay together:

• When the alert fires (monitorCondition: Fired), the incident opens and paging starts.
• When the alert resolves (monitorCondition: Resolved), the same incident is closed.
• Repeated deliveries of the same state are recognized and ignored, so a retry can’t double-page anyone.

Resolution depends on the Azure alert type. Stateful metric alerts and stateful log-search alerts can send a Resolved notification. Stateless metric alerts, stateless log-search alerts, and all activity-log alerts do not. When Azure sends no resolved notification, the WarnFire incident stays open until an authorized operator force-resolves it with a reason .

What shows up on the incident

WarnFire maps your Azure alert to the incident automatically:

Verify it worked

1. Follow Test before you connect , choose azure, and confirm the preview maps the expected action, title, severity, correlation key, and metadata. Preview does not select or verify a service.
2. Choose the intended service for Send test, send the confirmed test, and verify that one test incident opens for that service and pages its on-call responder.
3. Fire a disposable stateful Azure metric or log-search alert, then let it return to resolved. Confirm that one WarnFire incident opens and that the same incident closes. For a stateless or activity-log alert, verify the open event and plan an authorized manual force-resolution procedure.

Send test, Azure’s test action, and a disposable alert all use a real incident path. They can page responders; selected SMS and voice deliveries consume allowance or prepaid credits and can invoke configured auto-recharge. Notify the responder before testing.

If alerts don’t arrive

Next steps

Use Preview a mapping again before changing the action group or payload in production.