Skip to main content

Overview

PagerDuty integrates with Devin as an alert routing mechanism. When incidents fire in PagerDuty, they trigger Devin sessions via the Devin API through a lightweight webhook bridge. Devin then investigates the incident automatically — pulling telemetry, tracing root causes, and optionally opening fix PRs. This pattern works especially well when combined with the Datadog MCP integration, where PagerDuty routes the alert to Devin and Devin uses Datadog to investigate logs and metrics.

Setup

1

Deploy a webhook bridge service

Build a small handler that receives PagerDuty incident payloads and calls the Devin API to start investigation sessions.Create a service user in Settings > Service Users with ManageOrgSessions permission. Store the API token as DEVIN_API_KEY, your organization ID as DEVIN_ORG_ID, and a shared secret as WEBHOOK_SECRET on your bridge service. You’ll configure this same secret in PagerDuty’s webhook Custom Headers in the next step.
Deploy this anywhere that can receive HTTPS traffic — a Cloudflare Worker, AWS Lambda, or a small container.
2

Add a webhook integration in PagerDuty

  1. In PagerDuty, go to Services > [your service] > Integrations
  2. Click Add Integration and select Generic Webhooks (v3)
  3. Set the Webhook URL to your bridge service endpoint (e.g., https://your-bridge.example.com/pagerduty-alert)
  4. Under Custom Headers, add X-Webhook-Secret with the same value you stored as WEBHOOK_SECRET on your bridge service
  5. Under Event Subscription, filter by event type incident.triggered to only fire on new incidents
3

Verify the pipeline

Trigger a test incident in PagerDuty (or use a test service) and confirm that:
  1. Your bridge receives the webhook payload
  2. A new Devin session is created at app.devin.ai
  3. Devin begins investigating the incident

Best Practices

  • Start with warning-level monitors. Test the pipeline with non-critical incidents before routing production P1 alerts to Devin.
  • Filter by service or severity. Use PagerDuty’s webhook event subscriptions or add logic in your bridge to skip low-priority or noisy services. This prevents Devin from being overwhelmed with low-value alerts.
  • Use different playbooks per severity. Route P1 alerts for immediate investigation and hotfix. Route P3 alerts for root-cause analysis only. Pass different playbook_id values in the Devin API request based on urgency.
  • Tag sessions for tracking. The example code tags each session with pagerduty-triage and the service name, making it easy to filter and review in the Devin dashboard.

Combining with Datadog

PagerDuty is often used alongside the Datadog MCP integration. In this pattern:
  1. PagerDuty routes the alert to Devin (triggering the investigation session)
  2. Devin uses the Datadog MCP to query logs, metrics, and traces for the affected service
This gives Devin both the alert context from PagerDuty and deep observability data from Datadog, resulting in more thorough investigations.
Add Knowledge about your service architecture and on-call runbooks so Devin can follow your team’s investigation procedures automatically.