Deploy a webhook bridge
Create a small service that listens for PagerDuty Create a service user in Settings > Service Users at app.devin.ai with
incident.resolved events and starts a Devin session to write the postmortem. Deploy this as a serverless function (AWS Lambda, Cloudflare Worker) or a lightweight container:ManageOrgSessions permission. Copy the API token shown after creation and store it as DEVIN_API_KEY on your bridge service. Set DEVIN_ORG_ID to your organization ID — get it by calling GET https://api.devin.ai/v3/enterprise/organizations with your token. Set WEBHOOK_SECRET to a shared secret you’ll also configure in PagerDuty.Configure PagerDuty
- In PagerDuty, go to Services > [your service] > Integrations
- Click Add Integration and select Generic Webhooks (v3)
- Set the Webhook URL to your bridge endpoint (e.g.,
https://your-bridge.example.com/pagerduty-resolved) - Under Custom Headers, add
X-Webhook-Secretwith the same value you stored asWEBHOOK_SECRET - Under Event Subscription, filter by event type
incident.resolvedso the postmortem triggers only after the incident is closed
You can also subscribe to
incident.acknowledged if you want Devin to start gathering data while the incident is still in progress, then finalize the postmortem on resolution.Connect observability MCPs (optional)
Devin writes better postmortems when it can access your telemetry data. Enable one or more MCPs so Devin can pull real data for the incident window:Datadog MCP — Go to Settings > MCP Marketplace, find Datadog, click Enable, and enter your API/Application keys. Devin will query logs, metrics, deploy events, and monitor history.Sentry MCP — Find Sentry in the MCP Marketplace, click Enable, and complete the OAuth flow. Devin will pull error details, stack traces, and release tags.Once connected, Devin automatically correlates telemetry with the incident timeline to build an evidence-backed postmortem. Learn more about connecting MCP servers.
What Devin generates
When a PagerDuty incident resolves, Devin analyzes the incident window and drafts a structured postmortem:Example postmortem Devin produces:
Customize the postmortem
Tailor the pipeline to match your team’s postmortem process:Use a Playbook to define your postmortem template — sections, severity classification, required fields, and where to store the output. Pass a
playbook_id in the API request to standardize every postmortem.Route by severity. Add logic in your bridge to only generate postmortems for P1/P2 incidents. Lower-severity incidents might not need a full writeup.Add Knowledge about your architecture, service ownership, and past incidents so Devin can connect the dots — e.g., “orders-service depends on inventory-service, which is known for timeout issues under load.”Post to your wiki. Instead of committing to a repo, have Devin post the postmortem to Confluence, Notion, or your internal wiki via the session prompt.