Skip to main content
Für eine ausführlichere Anleitung zur PagerDuty-Integration klicken Sie hier.
1

Webhook-Bridge bereitstellen

Erstellen Sie einen kleinen Dienst, der auf PagerDuty-incident.resolved-Ereignisse reagiert und eine Devin-Sitzung startet, um das Postmortem zu verfassen. Stellen Sie ihn als serverlose Funktion (AWS Lambda, Cloudflare Worker) oder als schlanken Container bereit:
const express = require('express');
const crypto = require('crypto');
const app = express();
app.use(express.json());

function verifySignature(req) {
  const secret = Buffer.from(req.headers['x-webhook-secret'] || '');
  const expected = Buffer.from(process.env.WEBHOOK_SECRET || '');
  if (!expected.length) throw new Error('WEBHOOK_SECRET environment variable is not set');
  if (secret.length !== expected.length) return false;
  return crypto.timingSafeEqual(secret, expected);
}

app.post('/pagerduty-resolved', async (req, res) => {
  if (!verifySignature(req)) return res.status(401).send('Bad signature');

  const event = req.body?.event;
  if (!event || event.event_type !== 'incident.resolved') {
    return res.sendStatus(200);
  }

  const incident = event.data;
  const title = incident.title || 'Unknown incident';
  const service = incident.service?.summary || 'unknown-service';
  const urgency = incident.urgency || 'high';
  const incidentUrl = incident.html_url || '';
  const createdAt = incident.created_at || '';
  const resolvedAt = incident.resolved_at || new Date().toISOString();

  const orgId = process.env.DEVIN_ORG_ID;
  const response = await fetch(
    `https://api.devin.ai/v3/organizations/${orgId}/sessions`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.DEVIN_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      prompt: [
        `A PagerDuty incident has been resolved. Draft a postmortem.`,
        ``,
        `Incident: "${title}"`,
        `Service: ${service}`,
        `Urgency: ${urgency}`,
        `Created: ${createdAt}`,
        `Resolved: ${resolvedAt}`,
        `Incident URL: ${incidentUrl}`,
        ``,
        `Write a structured postmortem:`,
        `1. Use the Datadog MCP to pull logs and metrics for ${service} during the incident window`,
        `2. Identify the root cause — check for deploys, config changes, or upstream failures`,
        `3. Build a detailed timeline from first alert to resolution`,
        `4. List action items to prevent recurrence`,
        `5. Post the postmortem as a PR to our docs/postmortems/ directory`,
      ].join('\n'),
      tags: ['pagerduty-postmortem', `service:${service}`],
    }),
  });

  const { session_id } = await response.json();
  console.log(`Started postmortem session ${session_id} for: ${title}`);
  res.sendStatus(200);
});

app.listen(3000);
Erstellen Sie in Settings > Service Users unter app.devin.ai einen Service-Benutzer mit der Berechtigung ManageOrgSessions. Kopieren Sie das nach dem Erstellen angezeigte API-Token und speichern Sie es auf Ihrem Bridge-Service als DEVIN_API_KEY. Setzen Sie DEVIN_ORG_ID auf die ID Ihrer Organisation — Sie erhalten sie, indem Sie mit Ihrem Token GET https://api.devin.ai/v3/enterprise/organizations aufrufen. Setzen Sie WEBHOOK_SECRET auf ein gemeinsames Secret, das Sie auch in PagerDuty konfigurieren.
2

PagerDuty konfigurieren

  1. Gehen Sie in PagerDuty zu Services > [your service] > Integrations
  2. Klicken Sie auf Add Integration und wählen Sie Generic Webhooks (v3) aus
  3. Setzen Sie die Webhook URL auf Ihren Bridge-Endpunkt (z. B. https://your-bridge.example.com/pagerduty-resolved)
  4. Fügen Sie unter Custom Headers X-Webhook-Secret mit demselben Wert hinzu, den Sie als WEBHOOK_SECRET gespeichert haben
  5. Filtern Sie unter Event Subscription nach dem Ereignistyp incident.resolved, damit das Postmortem erst ausgelöst wird, wenn der Vorfall geschlossen ist
Sie können auch incident.acknowledged abonnieren, wenn Devin bereits während des laufenden Vorfalls mit dem Sammeln von Daten beginnen und das Postmortem dann nach der Behebung abschließen soll.
3

Observability-MCPs anbinden (optional)

Devin schreibt bessere Postmortems, wenn es auf Ihre Telemetriedaten zugreifen kann. Aktivieren Sie einen oder mehrere MCPs, damit Devin echte Daten für den Zeitraum des Vorfalls abrufen kann:Datadog MCP — Gehen Sie zu Settings > MCP Marketplace, suchen Sie Datadog, klicken Sie auf Enable und geben Sie Ihre API- und Application-Schlüssel ein. Devin fragt Logs, Metriken, Deployment-Ereignisse und den Monitor-Verlauf ab.Sentry MCP — Suchen Sie Sentry im MCP Marketplace, klicken Sie auf Enable und schließen Sie den OAuth-Vorgang ab. Devin ruft Fehlerdetails, Stacktraces und Release-Tags ab.Sobald die Verbindung hergestellt ist, korreliert Devin Telemetriedaten automatisch mit der Zeitachse des Vorfalls, um ein evidenzbasiertes Postmortem zu erstellen. Erfahren Sie mehr über das Verbinden von MCP-Servern.
4

Was Devin erstellt

Wenn sich ein PagerDuty-Vorfall bezieht, analysiert Devin den Zeitraum des Vorfalls und erstellt ein strukturiertes Postmortem:Beispiel für ein Postmortem, das Devin erstellt:
# Postmortem: Database Connection Pool Exhaustion — orders-service
**Date:** 2026-02-10 | **Duration:** 46 minutes | **Severity:** P1

## Summary
orders-service experienced connection pool exhaustion between
14:32 and 15:18 UTC, causing 502 errors for ~12% of order
placement requests.

## Timeline
- 14:15 UTC — Deploy #387 released (commit e4f29a1)
- 14:28 UTC — Connection pool usage climbed from 60% to 92%
- 14:32 UTC — Pool exhausted; PagerDuty incident triggered
- 14:38 UTC — On-call engineer acknowledged
- 14:45 UTC — Identified Deploy #387 added a new inventory
              check that opens a DB connection per line item
              without releasing it in the finally block
- 15:02 UTC — Rollback to Deploy #386 initiated
- 15:18 UTC — Connection pool recovered; incident resolved

## Root Cause
Deploy #387 introduced `checkInventoryAvailability()` in
`src/services/orders.ts:142`. The function opens a new DB
connection for each line item in an order but only releases
it on the success path. When inventory checks fail (timeout
or stock unavailable), connections leak.

Orders with 5+ line items reliably exhausted the pool within
15 minutes of the deploy.

## Action Items
- [ ] Fix connection leak: add `finally` block to release
      connection (PR #388 opened)
- [ ] Add connection pool usage monitor with alert at 80%
- [ ] Add integration test for multi-item orders with
      simulated inventory failures
- [ ] Review other DB access patterns for similar leak risks
5

Postmortem anpassen

Passen Sie die Pipeline an den Postmortem-Prozess Ihres Teams an:Verwenden Sie ein Playbook, um Ihre Postmortem-Vorlage festzulegen — Abschnitte, Schweregradklassifizierung, Pflichtfelder und den Speicherort für die Ausgabe. Übergeben Sie in der API-Anfrage eine playbook_id, um jedes Postmortem zu standardisieren.Nach Schweregrad weiterleiten. Fügen Sie in Ihrer Bridge Logik hinzu, um Postmortems nur für Vorfälle der Schweregrade P1/P2 zu erstellen. Vorfälle mit niedrigerem Schweregrad erfordern möglicherweise keine vollständige Ausarbeitung.Fügen Sie Knowledge zu Ihrer Architektur, Service-Verantwortung und früheren Vorfällen hinzu, damit Devin Zusammenhänge erkennen kann — z. B. “orders-service hängt von inventory-service ab, das unter Last bekanntermaßen Timeout-Probleme hat.”In Ihrem Wiki veröffentlichen. Statt in ein Repo zu committen, lassen Sie Devin das Postmortem über den Sitzungs-Prompt in Confluence, Notion oder Ihrem internen Wiki veröffentlichen.