Skip to main content
Para um guia mais detalhado de integração com o PagerDuty, clique aqui.
1

Implantar uma ponte para webhooks

Crie um pequeno serviço que monitore eventos incident.resolved do PagerDuty e inicie uma sessão do Devin para redigir o postmortem. Implante isso como uma função serverless (AWS Lambda, Cloudflare Worker) ou um contêiner leve:
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);
Crie um usuário de serviço em Configurações > Service Users no app.devin.ai com a permissão ManageOrgSessions. Copie o token da API exibido após a criação e armazene-o como DEVIN_API_KEY no seu serviço de bridge. Defina DEVIN_ORG_ID como o ID da sua organização — obtenha-o fazendo uma chamada a GET https://api.devin.ai/v3/enterprise/organizations com seu token. Defina WEBHOOK_SECRET como um segredo compartilhado que você também configurará no PagerDuty.
2

Configurar PagerDuty

  1. No PagerDuty, vá para Services > [seu serviço] > Integrations
  2. Clique em Add Integration e selecione Generic Webhooks (v3)
  3. Defina a Webhook URL como o endpoint da sua bridge (por exemplo, https://your-bridge.example.com/pagerduty-resolved)
  4. Em Custom Headers, adicione X-Webhook-Secret com o mesmo valor que você armazenou como WEBHOOK_SECRET
  5. Em Event Subscription, filtre pelo tipo de evento incident.resolved para que o postmortem seja acionado somente após o incidente ser encerrado
Você também pode se inscrever em incident.acknowledged se quiser que o Devin comece a coletar dados enquanto o incidente ainda estiver em andamento e depois finalize o postmortem quando ele for resolvido.
3

Conecte MCPs de observabilidade (opcional)

Devin escreve post-mortems melhores quando pode acessar seus dados de telemetria. Ative um ou mais MCPs para que o Devin possa buscar dados reais do período do incidente:Datadog MCP — Vá para Configurações > MCP Marketplace, encontre Datadog, clique em Ativar e insira suas chaves de API e de aplicativo. Devin consultará logs, métricas, eventos de deploy e histórico dos monitores.Sentry MCP — Encontre Sentry no MCP Marketplace, clique em Ativar e conclua o fluxo de OAuth. Devin buscará detalhes de erros, stack traces e tags de release.Depois de conectado, Devin correlaciona automaticamente a telemetria com a linha do tempo do incidente para elaborar um post-mortem baseado em evidências. Saiba mais sobre como conectar servidores MCP.
4

O que Devin gera

Quando um incidente no PagerDuty é resolvido, Devin analisa o período do incidente e elabora um postmortem estruturado:Exemplo de postmortem produzido pelo Devin:
# 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

Personalize o post-mortem

Adapte o pipeline para se alinhar ao processo de postmortem da sua equipe:Use um Playbook para definir seu modelo de postmortem — seções, classificação de severidade, campos obrigatórios e onde armazenar o resultado. Passe um playbook_id na solicitação da API para padronizar cada postmortem.Encaminhe por severidade. Adicione lógica à sua integração para gerar postmortems apenas para incidentes P1/P2. Incidentes de menor severidade podem não precisar de um relatório completo.Adicione Knowledge sobre sua arquitetura, os responsáveis pelos serviços e incidentes anteriores para que Devin consiga ligar os pontos — por exemplo, “orders-service depende de inventory-service, que é conhecido por problemas de timeout sob carga.”Publique no seu wiki. Em vez de fazer commit em um repo, faça com que Devin publique o postmortem no Confluence, Notion ou no wiki interno da sua empresa por meio do prompt da sessão.