🔗 Integrate Azure DevOps and PagerDuty With Microsoft Teams for Closed-Loop ChatOps

The tools that page you, build your code, and host your conversations are usually three different products. The teams that run smoothly aren’t the ones that picked the perfect tools — they’re the ones that wired the tools together so engineers don’t tab-hop during an incident. For me, Teams is the hub, and Azure DevOps and PagerDuty are the spokes.

Here’s how I connect them into a closed loop: build status and pages flow into Teams, and acknowledgements flow back out without anyone leaving the channel.

The goal: closed-loop, not just notifications

Most integrations are one-way — a firehose of “pipeline failed” and “incident triggered” messages you can’t act on. The version worth building is bidirectional:

• Azure DevOps pipeline events → rich cards in Teams.
• PagerDuty incidents → cards with Acknowledge / Resolve buttons.
• Clicking those buttons → calls back to PagerDuty’s API.

When acknowledge happens in the channel, the loop is closed and the context stays in one place.

Azure DevOps → Teams

Azure DevOps has two integration paths into Teams; use both for different jobs.

Service hooks are the granular option. In Project Settings → Service Hooks, create a hook for “Build completed” or “Release deployment completed” pointing at a Teams Workflow URL. You control the exact event and the payload, which means you can render a tailored card:

{
  "type": "message",
  "attachments": [{
    "contentType": "application/vnd.microsoft.card.adaptive",
    "content": {
      "type": "AdaptiveCard",
      "version": "1.5",
      "body": [
        { "type": "TextBlock", "text": "❌ Build failed: checkout-api #1842", "weight": "Bolder" },
        { "type": "FactSet", "facts": [
          { "title": "Branch", "value": "main" },
          { "title": "Triggered by", "value": "alice" },
          { "title": "Failed stage", "value": "integration-tests" }
        ]}
      ],
      "actions": [
        { "type": "Action.OpenUrl", "title": "View build", "url": "https://dev.azure.com/.../build/1842" }
      ]
    }
  }]
}

The official Azure DevOps app for Teams is the low-effort option — it subscribes a channel to pipelines, PRs, and work items with simple commands. Use it for general visibility; use service hooks when you need custom cards or routing logic.

PagerDuty → Teams, closing the loop

PagerDuty’s native Teams integration posts incident cards and — critically — lets responders acknowledge and resolve from the card. That’s the closed loop. When a page fires, the card lands in the on-call channel, and the responder clicks Acknowledge right there; PagerDuty updates because the integration calls back via its API.

If you need behavior the native app doesn’t cover, PagerDuty’s Events API v2 plus a custom card gives you full control:

curl -X POST "https://events.pagerduty.com/v2/enqueue" \
  -H "Content-Type: application/json" \
  -d '{
    "routing_key": "'$PD_KEY'",
    "event_action": "acknowledge",
    "dedup_key": "'$INCIDENT_KEY'"
  }'

A card button maps to that call, so “Acknowledge” in Teams becomes a real PagerDuty acknowledgement. Keep these credentials in a vault, not in the flow.

Tie it together: page creates a war room

The integration that earns its keep: when PagerDuty fires a Sev1, a flow not only posts the card but also creates a dedicated incident channel (via the Graph API), drops the PagerDuty card and the failing Azure DevOps build into it, and @-mentions on-call. Now the responder lands in a fully-prepared war room with the page, the suspect build, and the runbook already there.

Where AI sharpens the loop

The raw events are noisy. AI adds value by correlating and summarizing before a human reads anything:

• Correlate page to build. When a page fires, a model can line up the PagerDuty incident with the most recent Azure DevOps deploy and flag “checkout-api shipped v2.8.1 four minutes before this page” — the prime suspect, surfaced automatically. That’s the triage-correlation pattern applied across tools.
• Summarize the build failure. Instead of pasting 2,000 lines of log into the card, a model summarizes “integration test checkout_flow failed on a timeout” so the on-call reads one line.

As always, AI correlates and summarizes; it does not acknowledge pages or trigger deploys on its own. A human clicks the button. The prompt library has correlation prompts for exactly this.

Operational notes

• One routing key per service, not one global key — so you can route different services to different channels and revoke cleanly.
• Dedup keys matter. Reuse PagerDuty’s dedup_key when calling back so acknowledge/resolve hit the right incident.
• Mind webhook retries. Both Azure DevOps and PagerDuty retry failed deliveries; make your receiver idempotent or you’ll get duplicate channels.
• Watch for circular noise. Don’t let a “resolved” event re-trigger a flow that posts another card that triggers another event.

Build it loop by loop

Don’t wire everything at once. Start with PagerDuty pages landing in the on-call channel with working Acknowledge buttons — that one closed loop changes how on-call feels. Then add Azure DevOps build failures, then the auto-war-room, then the AI correlation. Each loop you close removes one reason to tab away from Teams during the worst ten minutes of someone’s week.

AI-driven correlation and summaries are advisory. Acknowledging pages and triggering deploys must remain explicit human actions backed by vaulted credentials.