Recursos · Integración n8n

Integración PagerDuty n8nAutomatiza PagerDuty con n8n.

Una alerta que despierta a alguien tendría que llegar ya con su contexto. La integración PagerDuty n8n mete 9 operaciones y 4 recursos dentro de un flujo de trabajo: incidentes, notas, entradas de log y usuarios. PagerDuty no tiene nodo trigger en n8n, así que el flujo arranca en otro sitio.

Reseñas verificadas en Trustpilot · Agencia de IA, automatización y growth

Por qué automatizar

¿Qué cubre la integración PagerDuty n8n?

El nodo PagerDuty viene incluido en n8n y habla con la API REST de PagerDuty por ti. Expone 9 operaciones repartidas en 4 recursos: Incident, Incident Note, Log Entry y User. Con eso un flujo abre un incidente, lo vuelve a leer, lista los incidentes de un periodo, cambia su estado, le añade notas, recupera entradas de log y busca a un usuario, siempre con el mismo credential creado una sola vez.

Conviene aclararlo desde el principio: no existe un nodo trigger de PagerDuty en n8n. Nada del lado de PagerDuty arranca un flujo por su cuenta. El punto de partida es otro: un Schedule Trigger que se ejecuta cada cierto intervalo, un nodo Webhook de n8n (una URL que n8n publica para que un servicio externo la llame), o el trigger de otra herramienta. PagerDuty entra después, como acción.

Hay tres usos que se repiten. Uno: convertir una comprobación propia en guardia real. Un flujo programado consulta una API o una base de datos, detecta el fallo y llama a incident.create sobre el servicio correcto. Dos: enriquecer antes de avisar. El incidente ya existe, el flujo lo lee, recoge las últimas entradas de log, resuelve a la persona asignada con user.get y manda el resumen a Slack o a Telegram. Tres: el informe, con incident.getAll sobre un rango de fechas volcado en Google Sheets para la revisión de guardias.

Cerrar el círculo importa tanto como abrirlo. Cuando la monitorización indica que el servicio vuelve a responder, incident.update pasa el estado a resolved y escribe en Resolution lo que pasó de verdad. El incidente queda con su propia conclusión, sin depender de la memoria de nadie.

Donde termina el nodo empieza HTTP Request. Cualquier endpoint de la API REST de PagerDuty sigue siendo accesible desde el nodo HTTP Request, que reutiliza el mismo credential de PagerDuty mediante la autenticación predefinida. Dos comportamientos que conviene prever: una lista solo devuelve todo si Return All está activado, porque si no n8n se detiene en Limit; y una búsqueda entre Since y Until cubre 6 meses como máximo.

Si las guardias son la primera automatización del equipo, la Reseña n8n cuenta en qué destaca la plataforma, y el Curso n8n monta paso a paso flujos de este tipo.

Conexión

¿Cómo se conecta PagerDuty con n8n?

  1. 01

    Crea el credential una vez en n8n

    En n8n, abre el menú Credentials y añade un credential de PagerDuty. Un credential son unas claves guardadas una sola vez: todos tus flujos lo encuentran después en el desplegable del nodo. El nodo admite dos métodos de autenticación, token API y OAuth2. El token es el camino corto para un flujo que se ejecuta sin nadie delante.

  2. 02

    Genera un token API de acceso general

    Para el método por token necesitas un API Token de acceso general. Dentro de PagerDuty entra en Integrations, luego Developer Tools, luego API Access Keys y por último Create New API Key. Copia la clave que aparece y pégala en el campo API Token del credential de n8n. Esa clave es la que el nodo envía en cada llamada a la API REST.

  3. 03

    O registra una app para OAuth2

    Para OAuth2, registra una nueva app de PagerDuty. En el desplegable Category elige Infrastructure Automation y en la sección Functionality marca OAuth 2.0. Guarda y edita la configuración de la app: en la sección OAuth 2.0 pulsa Add, copia la OAuth Callback URL que muestra n8n en el campo Redirect URL, lleva el Client ID y el Client Secret a n8n y elige Read/Write en Set Permission Scopes.

Acciones

Qué sabe hacer el nodo PagerDuty

El nodo PagerDuty expone 9 operaciones en 4 recursos. Para cada una: el nodo tal como lo configuras en n8n, los campos obligatorios y nuestras notas de campo.

Matriz recursos × operaciones
RecursoCreateGetGet ManyUpdate
Incident✓✓✓✓
Incident Note✓✓
Log Entry✓✓
User✓

Incident

4 operaciones
01

Create an incident

incident.create

Lo que ves en n8n

Notas y casos de uso

Abre un incidente en PagerDuty a partir de lo que el flujo acaba de detectar y devuelve el incidente creado.

Parámetros clave

  • Title: una descripción breve de los síntomas o la causa, construida desde la alerta con {{ $json.message }}.
  • Service Name or ID: el servicio sobre el que se crea el incidente, elegido en la lista o por expresión.
  • Email: un usuario válido de la cuenta, con formato name@email.com.
  • Incident Key: en Additional Fields, la clave de deduplicación. Otra petición con el mismo servicio y la misma clave se rechaza mientras siga abierto un incidente que coincida.
Casos de uso
falla la copia nocturna y el flujo abre un solo incidente, porque la clave absorbe los reintentos.
02

Get an incident

incident.get

Lo que ves en n8n

Notas y casos de uso

Recupera un incidente concreto. Es la forma limpia de comprobar en qué punto está una alerta antes de tocarla.

Parámetros clave

  • Incident ID: el identificador único del incidente, no su título. Suele llegar de un nodo anterior como {{ $json.id }}.
Casos de uso
un flujo de recordatorio relee el incidente un cuarto de hora después de abrirse y solo insiste si el estado sigue igual.
03

Get many incidents

incident.getAll

Lo que ves en n8n

Notas y casos de uso

Lista los incidentes de la cuenta, con una colección Options de 12 filtros para dejar solo lo que necesita el informe.

Parámetros clave

  • Return All: activado, n8n encadena las páginas de la API y trae todos los incidentes que coinciden; desactivado, Limit marca el máximo.
  • Statuses: deja solo los incidentes triggered, acknowledged o resolved.
  • Since y Until: principio y final del rango buscado, limitado a 6 meses.
  • Include: añade detalles como las personas asignadas o los servicios.
Casos de uso
la exportación del lunes con los incidentes disparados la semana anterior, ordenada con Sort By.
04

Update an incident

incident.update

Lo que ves en n8n

Notas y casos de uso

Modifica un incidente que ya existe. Estado, título, urgencia, prioridad y escalado caben en una colección Update Fields de 7 entradas.

Parámetros clave

  • Incident ID: el incidente al que se aplica el cambio.
  • Email: la dirección de un usuario válido de la cuenta, obligatoria también aquí.
  • Status: acknowledged o resolved.
  • Resolution: el texto de resolución, que solo tiene sentido si el estado pasa a resolved.
  • Escalation Level: sube el incidente a ese nivel de su política de escalado.
Casos de uso
la monitorización ve el servicio restablecido, el flujo resuelve el incidente y guarda la causa en Resolution.

Incident Note

2 operaciones
05

Create an incident note

incidentNote.create

Lo que ves en n8n

Notas y casos de uso

Añade una nota a un incidente. Así deja una automatización el contexto a quien coge la guardia de madrugada.

Parámetros clave

  • Incident ID: el incidente al que se engancha la nota.
  • Content: el texto de la nota, donde el flujo deja las líneas de log que fallan o el enlace al procedimiento.
  • Email: otra vez un usuario válido de la cuenta que hace la petición.
Casos de uso
segundos después de abrirse el incidente, un segundo nodo publica los últimos errores como nota. Quien responde empieza con pruebas, no con una búsqueda.
06

Get many incident notes

incidentNote.getAll

Lo que ves en n8n

Notas y casos de uso

Relee de golpe las notas ya guardadas en un incidente, en vez de ir a buscarlas de una en una.

Parámetros clave

  • Incident ID: las notas pertenecen a un solo incidente, por eso este campo es obligatorio.
  • Return All: todas las notas del incidente; sin marcar, Limit decide cuántas vuelven.
Casos de uso
cerrado el incidente, el flujo de post mortem reúne sus notas y las publica en un solo mensaje en Discord.

Log Entry

2 operaciones
07

Get a log entry

logEntry.get

Lo que ves en n8n

Notas y casos de uso

Trae una entrada de log concreta. Una entrada de log es el registro que PagerDuty guarda de un solo hecho sobre un incidente: un disparo, una aceptación, una notificación enviada.

Parámetros clave

  • Log Entry ID: el identificador único de esa entrada, tomado de un listado anterior como {{ $json.id }}.
Casos de uso
un flujo de auditoría aísla la entrada que aceptó un incidente para dejar por escrito quién lo hizo y a qué hora.
08

Get many log entries

logEntry.getAll

Lo que ves en n8n

Notas y casos de uso

Devuelve las entradas de log de la cuenta en un periodo. Es lo más parecido a un historial de actividad que ofrece el nodo, con una colección Options de 5 filtros.

Parámetros clave

  • Return All: todas las entradas página a página, o Limit para una muestra.
  • Is Overview: activado, vuelven solo los cambios más importantes del incidente, lo que mantiene legible una cronología.
  • Since y Until: la ventana de búsqueda, también con tope de 6 meses.
  • Timezone Name or ID: sin este campo las fechas vuelven en UTC.
Casos de uso
la revisión semanal recoge las entradas de resumen y las convierte en cronología.

User

1 operación
09

Get a user

user.get

Lo que ves en n8n

Notas y casos de uso

Busca a un usuario de la cuenta de PagerDuty y devuelve su ficha, para poner un nombre detrás de un identificador.

Parámetros clave

  • User ID: el identificador único del usuario, leído desde un incidente en lugar de escrito a mano.
Casos de uso
tras leer un incidente, el flujo convierte a la persona asignada en nombre y dirección, y manda el mensaje de relevo con Gmail.
Necesitas ayuda

¿Necesitas ayuda para automatizar PagerDuty con n8n?

El equipo te responde directamente.

Cada mensaje lo lee una persona.

FAQ

PagerDuty y n8n, dudas frecuentes

01¿La integración PagerDuty n8n es gratuita?
Sí, en la parte de n8n. El nodo de PagerDuty viene incluido con n8n: no hay nada que instalar ni coste adicional por el nodo, tanto en n8n Cloud, la oferta alojada por n8n, como en una instancia autoalojada en Community Edition con licencia Sustainable Use. Un flujo se comporta igual en los dos casos, así que puedes probar en Cloud y llevar después el mismo flujo a tu Docker. Lo que cueste una suscripción de PagerDuty es otra cuestión y esta página no entra en ella.
02¿Qué credentials necesita el nodo de PagerDuty?
Se admiten dos métodos de autenticación: token API y OAuth2. Para el token, genera un API Token de acceso general en PagerDuty desde Integrations, luego Developer Tools, luego API Access Keys y Create New API Key, y pégalo en el credential de n8n. Para OAuth2, registra una app de PagerDuty con Category en Infrastructure Automation y OAuth 2.0 marcado en Functionality, copia la OAuth Callback URL de n8n en el campo Redirect URL de la app, lleva el Client ID y el Client Secret a n8n y selecciona Read/Write en Set Permission Scopes. El credential se crea una vez y sirve para todos los flujos.
03¿Qué límites tiene el nodo de PagerDuty?
El nodo expone 9 operaciones sobre 4 recursos: Incident, Incident Note, Log Entry y User. Para todo lo demás de la API REST de PagerDuty está el nodo HTTP Request, que llama a cualquier endpoint reutilizando el mismo credential de PagerDuty mediante la autenticación predefinida, así que no te quedas bloqueado ni manejas dos juegos de claves. Hay dos comportamientos que conviene prever: una lista solo devuelve el conjunto completo con Return All activado, porque si no Limit corta el resultado; y una búsqueda entre Since y Until abarca 6 meses como máximo, de modo que un informe más largo se arma en varias pasadas.
04¿PagerDuty puede disparar un flujo de n8n en tiempo real?
No. PagerDuty no tiene nodo trigger en n8n, así que nada del lado de PagerDuty arranca un flujo solo. Quedan tres caminos. El Schedule Trigger ejecuta el flujo cada cierto intervalo y consulta PagerDuty con una operación como incident.getAll, suficiente para informes y comprobaciones de seguimiento. El nodo Webhook de n8n da una URL que un servicio externo puede llamar, y entonces es ese servicio el que empuja la información. Y queda la opción de arrancar con el trigger de otra herramienta y dejar PagerDuty como acción al final de la cadena.
05¿n8n o Make para PagerDuty?
Depende de cuatro criterios, y ninguna de las dos herramientas es mala. El alojamiento: n8n se instala en tu propio servidor con Docker o npm, o se usa en n8n Cloud, mientras que Make existe solo alojado. De ahí sale el control de los datos, porque una instancia autoalojada mantiene el contenido de los incidentes y los correos de los usuarios en tu infraestructura. El modelo de coste: Make factura por operación, algo que pesa en cuanto un flujo lista muchos incidentes o entradas de log. Y la lógica visual: las dos se montan con el ratón, y la prueba honesta es rehacer un flujo de guardias en cada una.