Skip to content
Notifications
Clear all

Step-by-step: Integrating Sentinel with PagerDuty without using the expensive Logic App path

1 Posts
1 Users
0 Reactions
3 Views
(@martech_hoarder)
Trusted Member
Joined: 3 months ago
Posts: 47
Topic starter   [#1030]

Alright, fellow stack-hoarders 👋. We all know the drill: you get a juicy Sentinel alert that needs immediate human eyes, so you naturally look to PagerDuty. The official Microsoft path? Logic Apps. And while that *works*, the cost can spiral faster than a poorly targeted ad spend campaign. Every alert processed is a transaction. No thank you.

I've been down that road and found a much leaner, meaner, and frankly more controllable path using **Azure Functions**. It's not *no-code*, but it's not crazy either. You own the compute cost, which for alert routing is pennies compared to Logic Apps. Here's my battle-tested method.

**The Core Idea:** Instead of a Logic App, you use a simple Azure Function (HTTP trigger) as your Sentinel webhook destination. This function reformats the Sentinel incident or alert JSON into the shape PagerDuty's Events API v2 expects and fires it off.

**My Step-by-Step:**

1. **Create a PagerDuty Service & Integration:** In your PD account, create a new Service (e.g., "Azure Sentinel Alerts"). Add an "Events API V2" integration. Copy that **Integration Key** – this is your golden ticket.

2. **Spin up the Azure Function:** Go to your Azure portal, create a new Function App (Runtime stack: Node.js or Python, I used Node). Create a new HTTP trigger function. Set the authorization level to `Function`. You'll get a URL endpoint.

3. **The Bridge Code:** This function does three things:
* Receives the Sentinel webhook payload (set this up in Sentinel's Automation rules -> Action: Trigger Webhook).
* Transforms the payload. PagerDuty needs a `severity` mapping (I map Sentinel's `High` to `critical`, `Medium` to `warning`, etc.), a clean title, and the incident link.
* Sends the POST request to PagerDuty's ` https://events.pagerduty.com/v2/enqueue` endpoint with your Integration Key.

4. **Key Configuration Bits:**
* In Sentinel, your Automation Rule should filter for when incidents are created (or status changes).
* The webhook payload should be the incident object – gives you all the context.
* In your Function code, make sure to handle the `acknowledge` and `resolve` events from Sentinel if you want bi-directional sync (more advanced, but doable).

**Why this over Logic Apps?**
* **Cost:** Azure Function consumption plan costs are negligible for this volume. You escape the per-action pricing model.
* **Control:** You can add custom logic, filter out noisy alerts before they hit PD, or enrich with data from other sources.
* **Transparency:** It's your code, in your repo. You're not dragging through a GUI connector that might change.

The only "trap" here is maintaining the code yourself, but it's ~50 lines of straightforward logic. For anyone tired of the connector tax, this is a solid, reliable workhorse.


one stack at a time


   
Quote