Azure Log Alerts Integration

Azure Monitor's log-based alerts fire when a query result crosses a threshold you define. Getting those alerts into your on-call flow means pointing an Action Group at your platform's webhook — the setup takes maybe ten minutes once you know where everything lives.

You'll need Monitor contributor rights on the subscription and the webhook URL from your platform's Integrations page before touching anything in Azure.

Setting Up the Alert Source

On your platform, go to Integrations → Inbound Integrations and add a new Azure Alerts source. The webhook URL gets generated at the end of the wizard — copy it and keep it somewhere handy, you'll paste it into Azure shortly.

Building the Alert Rule in Azure

In the Azure Portal, open Monitor → Alerts and hit Create → Alert rule.

Scope tab — the first thing Azure asks is what you're watching. Set the scope level to Subscription, then click Select scope. The panel that opens on the right shows your subscriptions and resource groups — pick whichever one makes sense for your use case and confirm.

Condition tab — this is where you define what triggers the alert. Signal name controls which activity stream gets monitored; "All Administrative operations" is a reasonable catch-all for tracking write/delete events across your subscription. The chart in the middle will start reflecting historical event data once you pick a signal.

Down below, Alert logic has three dropdowns: Event Level, Status, and Event initiated by. For a first-pass setup, leaving these at "All selected" is totally fine — you can tighten the filters later once you have a feel for what's actually firing.

Click Next: Actions when the condition looks right.

Creating the Action Group

Action groups are Azure's way of bundling together "what happens when this fires." On the Actions tab, create a new one.

Basics tab — name it something like oncall-webhook (the action group name can be longer, but the display name is capped at 12 characters, so plan accordingly — webhook works fine there). Subscription and resource group just need to match wherever you're deploying this, and Region can stay Global.

Actions tab — skip Notifications and jump straight here. Set Action type to Webhook, give the action a name like oncall, then click the edit icon. A panel slides in from the right with a URI field — paste your platform's webhook URL there. One thing worth double-checking: Enable the common alert schema should be flipped to Yes. Without it, the payload shape can vary between alert types, which tends to cause parsing issues on the receiving end. Hit OK to close the panel.

Click Review + create, then Create.

Finishing the Alert Rule

Back in the main alert rule wizard, scroll to Alert rule details and give the rule a name — something like activity-log-oncall is descriptive enough. Set the severity to match the criticality of what you're monitoring, then click Create alert rule.

Once it saves, the rule shows up in your alert rules list with status Enabled. That's the signal that everything is wired up correctly.

A Few Things Worth Knowing

Azure log alerts don't send a resolve notification when the condition clears — incidents created through this integration will need to be closed manually from your platform. This is an Azure limitation, not a platform one.

If the webhook stops receiving events, the most common culprit is the common alert schema being disabled on the action. Also worth checking: the action group is still attached to the alert rule (Azure sometimes detaches it if the group gets edited after the rule is saved).

The same action group can be reused across multiple alert rules — no need to recreate it each time you add a new rule.