Recursos · Conector de Claude

Conector Claude PagerDutyLo que Claude sabe hacer en tu cuenta de PagerDuty.

El conector Claude PagerDuty expone 64 herramientas. 42 leen incidentes, alertas, calendarios de guardia, servicios y páginas de estado; 22 pueden abrir incidentes, sumar intervinientes, cambiar turnos o borrar ajustes. Aquí ves qué hace cada una, qué apruebas tú y qué documentación manda.

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

Resumen

¿Qué cambia cuando Claude entra en tu PagerDuty?

Cuando algo se cae de madrugada, nadie quiere saltar entre cinco pantallas para averiguar quién está de guardia o qué se ha probado ya. Le preguntas a Claude y él consulta incidentes, notas, calendarios y eventos de cambio en PagerDuty mientras te contesta. Si hace falta dar el siguiente paso, lo prepara y espera a que lo apruebes.

Ponerte al día en mitad de la noche. list_incidents te dice qué sigue abierto, list_incident_notes qué intentaron ya los demás, y get_past_incidents o get_related_incidents si esto ya pasó antes o si otros equipos están con lo mismo.

Actuar sin cambiar de ventana. manage_incidents cambia el estado, la prioridad o a quién está asignado; add_responders suma intervinientes; add_note_to_incident deja constancia de lo hecho; y create_status_page_post publica un aviso en una página de estado.

Cuadrar las guardias. list_oncalls contesta a «¿a quién llamo ahora?» y create_schedule_override cubre el turno de un compañero enfermo con una sola frase.

Lo que la ficha del directorio no cuenta: sus 64 nombres vienen del servidor autoalojado de PagerDuty, que el propio fabricante ha archivado, mientras su servidor alojado actual documenta herramientas agrupadas. Más abajo lo explicamos. Y nada funciona solo: ninguna herramienta se activa cuando llega una alerta. Si quieres enlazar sus eventos con otras aplicaciones, mira la integración PagerDuty n8n o la integración PagerDuty Make.

Vocabulario

Cinco palabras antes de conectar

Las verás al conectar PagerDuty con Claude. Mejor tenerlas claras desde el principio.

Conector
El enlace que configuras una sola vez entre Claude y una cuenta que ya tienes, para que trabaje en ella mientras te responde.
Herramienta
Cada acción con nombre propio que el conector habilita. Claude elige solo las que necesita, y el directorio las enumera una a una.
Autorización
La pantalla de acceso del propio servicio, donde le das a Claude el permiso que usará. Se concede una vez por persona y se retira igual.
Aprobación
La confirmación que Claude espera antes de completar algo que modifica tu cuenta. Aparece en la conversación justo cuando importa.
MCP
El estándar común sobre el que se construyen los conectores: es lo que permite a un asistente como Claude hablar con un servicio externo.
Conexión

Conectar PagerDuty con Claude en tres pasos

  1. 01

    Encontrar PagerDuty en Claude

    En Claude, abre Customize y luego Connectors, y busca PagerDuty en la lista. En un espacio Team o Enterprise, primero un Owner o un Primary Owner tiene que activar el conector para que cada miembro pueda conectarse.

  2. 02

    Iniciar la conexión

    Pulsa Connect en su fila e inicia sesión en PagerDuty en la ventana que abre el propio PagerDuty. Si algún día la conexión falla, usa Disconnect y vuelve a conectar desde el mismo sitio.

  3. 03

    Revisar la pantalla de autorización

    Lee la pantalla de autorización de PagerDuty antes de aceptar. Es de PagerDuty, no de Claude, y es la que fija hasta dónde llega el acceso. Puedes retirarlo más adelante desde tu propia cuenta de PagerDuty.

Herramientas

Las 64 herramientas del conector Claude PagerDuty, según lo que hacen

PagerDuty le da a Claude 64 herramientas: 42 que leen tu cuenta, 22 que cambian algo en ella.

Dos grupos: lo que Claude consulta y lo que puede cambiar. La clasificación de lectura o escritura sale de la propia tabla de herramientas de PagerDuty para estos nombres exactos, que se quedan tal cual los muestra Claude.

  • 42 lectura
  • 22 escritura

Lo que Claude lee (42)

42 herramientas

Cuarenta y dos herramientas que consultan incidentes, alertas, calendarios, servicios, orquestaciones, páginas de estado, equipos y usuarios.

get_alert_from_incident

Recupera una alerta determinada dentro de un incidente, con el detalle que la señal traía al llegar. Claude la lee entera en vez de resumirte el incidente completo.

Cuándo sirve
un incidente agrupa varias alertas y quieres saber qué decía exactamente la que despertó a la persona de guardia.
Ojo
necesita saber de qué incidente cuelga la alerta; si no lo tienes, empieza por la lista de alertas del incidente.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_alert_grouping_setting

Muestra cómo está configurado un ajuste concreto de agrupación de alertas, es decir, la regla que decide qué alertas se juntan en un mismo incidente.

Cuándo sirve
te llegan diez incidentes por un solo fallo y sospechas que la agrupación de ese servicio no hace lo que debería.
Ojo
lee una sola configuración; para comparar varias, pide primero el listado completo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_change_event

Abre un evento de cambio en particular: por ejemplo un despliegue, con su detalle.

Cuándo sirve
en la cronología aparece un despliegue justo antes de la caída y quieres ver qué contenía antes de culparlo.
Ojo
que un cambio coincida en el tiempo con un incidente no prueba que lo haya causado; Claude te enseña el dato, la conclusión es tuya.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_escalation_policy

Lee una política de escalado: quién recibe el aviso primero, quién después y en qué orden sube la alerta si nadie responde.

Cuándo sirve
un aviso no le llegó a quien esperabas y quieres comprobar la cadena real, no la que recuerda el equipo.
Ojo
una política muestra niveles y destinatarios, no quién está de guardia ahora mismo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_event_orchestration

Consulta una orquestación de eventos concreta, el conjunto de reglas que PagerDuty aplica a los eventos entrantes antes de convertirlos en incidentes.

Cuándo sirve
un evento que debería haber abierto incidente se quedó en nada y quieres revisar por dónde pasó.
Ojo
las orquestaciones tienen varias capas (global, enrutador, servicio); mira también las herramientas de cada nivel.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_event_orchestration_global

Devuelve las reglas globales de orquestación, las que se aplican a todos los eventos antes de que se repartan entre servicios.

Cuándo sirve
varios servicios cambiaron de comportamiento a la vez y buscas una regla común que lo explique.
Ojo
una regla global afecta a todo lo que entra; léela con calma antes de sacar conclusiones sobre un solo servicio.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_event_orchestration_router

Muestra la configuración del enrutador de orquestación, la pieza que decide a qué servicio va cada evento que entra.

Cuándo sirve
las alertas de un sistema nuevo acaban en el servicio equivocado y quieres ver qué regla de enrutado las atrapa.
Ojo
el orden de las reglas cuenta; Claude te lo enseña tal cual, sin reordenarlo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_event_orchestration_service

Lee las reglas de orquestación de un servicio concreto, las que actúan después de que el enrutador le haya asignado el evento.

Cuándo sirve
un servicio se traga alertas que el equipo esperaba recibir y quieres localizar la regla culpable.
Ojo
son reglas de un único servicio; si el evento ni siquiera llega ahí, el problema está antes, en el enrutador.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_incident

Trae un incidente concreto a partir de su identificador, con su detalle.

Cuándo sirve
alguien pega en el chat el enlace de un incidente y quieres saber en qué punto está sin abrir PagerDuty.
Ojo
hace falta el identificador; para buscar por servicio, fecha o estado, usa el listado de incidentes.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_incident_workflow

Lee un flujo de trabajo de incidentes, la secuencia de pasos que PagerDuty ejecuta cuando alguien lo lanza sobre un incidente.

Cuándo sirve
antes de lanzar un flujo quieres saber exactamente qué hará: abrir un canal, avisar a alguien, publicar un estado.
Ojo
leerlo no lo lanza; para eso existe otra herramienta, de escritura.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_log_entry

Abre una entrada concreta del registro de actividad de la cuenta: quién hizo qué, sobre qué y cuándo.

Cuándo sirve
en la revisión posterior alguien pregunta quién resolvió el incidente y la respuesta está en una línea del registro.
Ojo
el registro recoge lo ocurrido, no el porqué; el contexto suele estar en las notas del incidente.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_outlier_incident

Obtiene el análisis de atipicidad de un incidente, es decir, si PagerDuty lo considera fuera de lo habitual para ese servicio.

Cuándo sirve
quieres saber si la alarma de esta madrugada es ruido de siempre o algo que merece despertar a más gente.
Ojo
es la lectura de PagerDuty sobre el incidente; úsala como pista, no como veredicto.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_past_incidents

Busca incidentes anteriores parecidos al que tienes delante, para ver si ya pasó y cómo se resolvió entonces.

Cuándo sirve
a las tres de la mañana te suena este error y quieres la nota de quien lo arregló la última vez.
Ojo
el parecido lo calcula PagerDuty; revisa que el incidente antiguo trate de verdad del mismo problema.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_schedule

Lee un calendario de guardia concreto tal como está configurado en PagerDuty.

Cuándo sirve
planificas las vacaciones de verano y quieres ver cómo gira la rotación del equipo de plataforma.
Ojo
para saber quién cubre una franja de horas concreta es más directa la herramienta que lista los usuarios del calendario.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_service

Consulta el detalle de un servicio concreto de PagerDuty.

Cuándo sirve
heredas un servicio que nadie documentó y quieres entender adónde van sus avisos antes de tocar nada.
Ojo
leer la configuración no la toca; los ajustes pasan por otra herramienta, la de actualización.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_status_page_post

Lee una publicación concreta de una página de estado, el aviso que tus clientes ven cuando algo falla.

Cuándo sirve
quieres revisar lo que se comunicó durante la última caída antes de redactar el informe para dirección.
Ojo
el texto es público para quien consulta tu página de estado; léelo pensando en ese lector.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_team

Muestra los datos de un equipo de PagerDuty tal como están registrados en la cuenta.

Cuándo sirve
un incidente menciona a un equipo que no conoces y quieres saber de quién se trata antes de sumarlo.
Ojo
para ver quién lo forma hace falta otra herramienta, la de miembros del equipo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

get_user_data

Devuelve la información del usuario autenticado, es decir, la cuenta con la que Claude está trabajando en PagerDuty.

Cuándo sirve
las respuestas de Claude no cuadran con lo que ves tú y quieres confirmar con qué cuenta está conectado.
Ojo
si la conexión se hizo con credenciales de cuenta y no de usuario, el resultado puede sorprenderte; PagerDuty admite ambas.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_alert_grouping_settings

Lista todos los ajustes de agrupación de alertas de la cuenta, para tener la foto completa de qué se agrupa y dónde.

Cuándo sirve
el volumen de incidentes se ha disparado y quieres saber qué servicios agrupan sus alertas y cuáles no.
Ojo
en una cuenta grande la lista es larga; pide a Claude que la filtre por el servicio que te interesa.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_alerts_from_incident

Enumera todas las alertas agrupadas dentro de un incidente, cada una con su propia señal de origen.

Cuándo sirve
un incidente arrastra decenas de alertas y quieres saber si vienen de un solo host o de toda la región.
Ojo
si el número te parece absurdo, revisa después el ajuste de agrupación de ese servicio.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_change_events

Recorre los eventos de cambio de todos los servicios, la lista de despliegues y ajustes que tus herramientas han notificado a PagerDuty.

Cuándo sirve
quieres un repaso de todo lo que se desplegó ayer por la tarde antes de que empezaran los avisos.
Ojo
abarca toda la cuenta; acótalo por fechas o te llegará más de lo que puedes leer.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_escalation_policies

Lista todas las políticas de escalado de la cuenta, para ver de un vistazo cuántas hay y cómo se llaman.

Cuándo sirve
preparas una auditoría de guardias y sospechas que hay políticas huérfanas que ya no usa ningún servicio.
Ojo
solo lista; para el detalle de cada nivel, Claude tendrá que abrirlas una a una.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_event_orchestrations

Enumera las orquestaciones de eventos configuradas en la cuenta, el punto de partida para entender cómo entra el tráfico de alertas.

Cuándo sirve
llegas nuevo al equipo de SRE y quieres un mapa de por dónde pasan los eventos antes de ser incidentes.
Ojo
el listado da los nombres; las reglas de cada una se leen con las herramientas de detalle.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_incident_change_events

Lista los eventos de cambio relacionados con un incidente concreto, para cruzar la caída con lo que se tocó justo antes.

Cuándo sirve
la pregunta de siempre en plena crisis: ¿quién desplegó qué antes de que esto se rompiera?
Ojo
la relación la establece PagerDuty; una lista vacía no demuestra que nadie tocara nada.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_incident_notes

Recoge las notas que los intervinientes han dejado en un incidente, el diario compartido de lo que se probó y lo que no.

Cuándo sirve
entras de relevo a mitad de un incidente y necesitas ponerte al día sin preguntar lo mismo en el canal.
Ojo
Claude solo ve lo que alguien escribió; lo que se habló por teléfono no está ahí.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_incident_workflows

Lista los flujos de trabajo de incidentes disponibles en la cuenta, cada uno con su nombre.

Cuándo sirve
quieres saber si ya existe un flujo para abrir la sala de crisis antes de montarlo a mano.
Ojo
conocer el flujo no basta para lanzarlo con seguridad; lee su detalle antes de pedir que se ejecute.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_incidents

Lista incidentes con filtros, y es la puerta de entrada a casi todo lo demás.

Cuándo sirve
empiezas el turno y preguntas a Claude qué sigue abierto y qué se resolvió durante la noche.
Ojo
PagerDuty avisa de que algunos filtros, como por equipo o por persona asignada, exigen autenticación a nivel de usuario.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_log_entries

Recorre las entradas del registro de actividad, la pista de auditoría de lo que ha pasado en la cuenta.

Cuándo sirve
en la revisión del incidente quieres la secuencia completa: quién lo reconoció, quién escaló y cuándo se cerró.
Ojo
el registro puede ser enorme; dale a Claude un incidente o un periodo concreto.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_oncalls

Muestra las asignaciones de guardia vigentes en toda la cuenta.

Cuándo sirve
la pregunta más repetida de cualquier empresa con guardias: ¿a quién llamo ahora mismo para este servicio?
Ojo
refleja el estado actual; si hubo un reemplazo de última hora, vuelve a preguntar antes de actuar.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_schedule_users

Lista quién está en un calendario de guardia durante un intervalo de tiempo que tú eliges.

Cuándo sirve
montas el calendario de festivos y quieres saber quién cubre la semana del puente.
Ojo
necesita un rango de fechas; sin él, Claude tendrá que preguntarte cuál.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_schedules

Enumera todos los calendarios de guardia de la cuenta, para situar cada rotación antes de entrar en detalle.

Cuándo sirve
quieres saber cuántas rotaciones distintas mantiene la empresa y cuáles parecen abandonadas.
Ojo
son nombres y poco más; la estructura de cada rotación se lee con la herramienta de un calendario.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_service_change_events

Recupera la historia reciente de un servicio concreto a través de sus eventos de cambio: despliegues y ajustes.

Cuándo sirve
el servicio de pagos empezó a fallar tras el cierre de la tarde y quieres ver solo sus cambios.
Ojo
abarca un único servicio; si la causa vino de una dependencia, mira también los cambios globales.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_services

Muestra el catálogo completo de servicios de la cuenta, las unidades que reciben alertas y abren incidentes.

Cuándo sirve
necesitas el identificador de un servicio para abrir un incidente o revisar sus reglas y no lo recuerdas.
Ojo
en cuentas con cientos de servicios, pídele a Claude que busque por nombre.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_status_page_impacts

Enumera las opciones de impacto que admite una página de estado, los valores posibles al describir qué parte se ve afectada.

Cuándo sirve
vas a pedir a Claude una publicación y quieres que use las categorías que tu página ya tiene definidas.
Ojo
son las opciones configuradas; Claude no puede inventar otras desde el conector.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_status_page_post_updates

Lista las actualizaciones sucesivas de una publicación de estado, en el orden en que se fueron comunicando.

Cuándo sirve
al cerrar la caída quieres reconstruir qué se contó a los clientes y a qué hora.
Ojo
muestra lo publicado; lo que el equipo decidió no contar no aparece.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_status_page_severities

Muestra los niveles de gravedad configurados en una página de estado.

Cuándo sirve
antes de publicar un aviso quieres comprobar si tu página distingue entre degradación y caída total.
Ojo
cada página puede tener los suyos; no des por hecho que coinciden entre páginas.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_status_page_statuses

Enumera los estados disponibles en una página de estado, como investigando o resuelto, según lo que tengas configurado.

Cuándo sirve
quieres que Claude marque la publicación con el estado correcto y no con uno que tu página no reconoce.
Ojo
los nombres exactos dependen de tu configuración; Claude los lee, no los adivina.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_status_pages

Reúne todas las páginas de estado de la cuenta, las que tus clientes consultan cuando algo va mal.

Cuándo sirve
tienes una página para clientes y otra interna y quieres asegurarte de que Claude publica en la correcta.
Ojo
publicar en la página equivocada es fácil si se parecen; revisa el nombre antes de aprobar cualquier escritura.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_team_members

Enumera quién forma parte de un equipo de PagerDuty.

Cuándo sirve
vas a sumar un equipo a un incidente y quieres saber a quién vas a despertar realmente.
Ojo
pertenecer al equipo no significa estar de guardia; para eso está la lista de guardias vigentes.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_teams

Te da la relación de equipos de la cuenta, útil para ubicar a quién pertenece cada servicio o calendario.

Cuándo sirve
reorganizáis departamentos y quieres ver qué equipos siguen existiendo en PagerDuty.
Ojo
los nombres de equipo suelen parecerse; confirma el identificador antes de pedir cualquier escritura.

Fuentegithub.com · 30 de septiembre de 2026 ↗

list_users

Saca la relación completa de usuarios de la cuenta de PagerDuty.

Cuándo sirve
quieres saber si una persona que dejó la empresa sigue dada de alta y figurando en rotaciones.
Ojo
ver a alguien en la lista no dice si está de guardia ni en qué equipos está; cruza con las otras herramientas.

Fuentegithub.com · 30 de septiembre de 2026 ↗

Lo que Claude puede cambiar (22)

22 herramientas

Veintidós herramientas que abren, suman, retocan, publican o borran. Ninguna fuente detalla su confirmación, así que vale la regla general de más abajo.

add_note_to_incident

Aprobación: ver la regla

Deja una nota en un incidente, en el diario compartido que leen todos los que intervienen.

Lo que Claude pide
ninguna fuente describe una confirmación propia de esta herramienta, así que se aplica la regla general de aprobaciones.
Cuándo sirve
acabas de reiniciar un nodo y quieres que el siguiente de guardia lo sepa sin repetir la prueba.
Ojo
las notas quedan para la revisión posterior; que Claude escriba hechos, no suposiciones.

Fuentegithub.com · 30 de septiembre de 2026 ↗

add_responders

Aprobación: ver la regla

Incorpora personas o equipos adicionales a la respuesta de un incidente.

Lo que Claude pide
no hay nada documentado para este caso concreto; cuenta con la regla general que se explica más abajo.
Cuándo sirve
la caída del cobro necesita ya al equipo de base de datos y no quieres buscar su guardia a mano.
Ojo
revisa los nombres de quienes se suman antes de aprobar.

Fuentegithub.com · 30 de septiembre de 2026 ↗

add_team_member

Aprobación: ver la regla

Da de alta a un usuario dentro de un equipo de PagerDuty.

Lo que Claude pide
no consta una confirmación específica; la cubre la aprobación por defecto de Claude.
Cuándo sirve
una nueva ingeniera se incorpora a plataforma y tiene que aparecer antes de rehacer la rotación.
Ojo
entrar en un equipo puede acabar metiéndola en avisos; confírmalo con quien gestiona las guardias.

Fuentegithub.com · 30 de septiembre de 2026 ↗

append_event_orchestration_router_rule

Aprobación: ver la regla

Añade una regla al enrutador de orquestación, que pasa a decidir hacia qué servicio va un tipo de evento.

Lo que Claude pide
ninguna fuente detalla qué pregunta Claude aquí; aplica la regla general de aprobaciones.
Cuándo sirve
conectas un sistema nuevo y sus alertas deben llegar al servicio de su equipo, no al genérico.
Ojo
una regla mal escrita puede desviar alertas reales a donde nadie mira; pide ver la configuración antes y después.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_alert_grouping_setting

Aprobación: ver la regla

Crea un ajuste nuevo de agrupación de alertas, que junta en un solo incidente las alertas que cumplan sus condiciones.

Lo que Claude pide
sin confirmación documentada para esta herramienta; rige la regla general.
Cuándo sirve
un servicio abre veinte incidentes por un único fallo y quieres que PagerDuty los reúna.
Ojo
agrupar demasiado esconde problemas distintos bajo un mismo incidente; empieza por un servicio.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_incident

Aprobación: ver la regla

Abre un incidente nuevo en PagerDuty.

Lo que Claude pide
las fuentes no describen una confirmación particular; se aplica la aprobación por defecto.
Cuándo sirve
un cliente importante te escribe por otro canal y quieres que la guardia se entere ya, sin esperar a que salte una alerta.
Ojo
asegúrate del servicio y de la urgencia antes de aprobar.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_schedule

Aprobación: ver la regla

Crea un calendario de guardia nuevo en la cuenta.

Lo que Claude pide
no hay confirmación documentada para esta herramienta; la regla general de aprobaciones la cubre.
Cuándo sirve
montas un equipo de soporte para una región nueva y necesita su propia rotación desde el lunes.
Ojo
un calendario vacío no protege a nadie hasta que una política de escalado lo usa; revisa esa parte también.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_schedule_override

Aprobación: ver la regla

Añade un reemplazo sobre un calendario: otra persona cubre una franja concreta sin tocar la rotación de fondo.

Lo que Claude pide
ninguna fuente describe un aviso propio; se aplica la regla general más abajo.
Cuándo sirve
un compañero cae enfermo por la tarde y tú, o quien se ofrezca, cubres su guardia de esta noche.
Ojo
comprueba la zona horaria del intervalo; un turno cubierto con horas desfasadas deja un hueco real.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_service

Aprobación: ver la regla

Registra un servicio nuevo en PagerDuty, la unidad que recibirá las alertas.

Lo que Claude pide
no consta ninguna confirmación específica; cubre la aprobación por defecto.
Cuándo sirve
lanzáis un microservicio y quieres tenerlo vigilado antes de abrirle tráfico real.
Ojo
un servicio sin la política correcta avisa a quien no toca; revisa cuál asigna Claude.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_status_page_post

Aprobación: ver la regla

Crea una publicación nueva en una página de estado, el aviso que tus clientes van a leer.

Lo que Claude pide
nada documentado para esta herramienta en particular; aplica la regla general de aprobaciones.
Cuándo sirve
la caída ya se nota fuera y quieres un primer aviso sobrio mientras el equipo investiga.
Ojo
el texto sale a la vista del público; léelo como lo leería un cliente enfadado antes de aprobar.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_status_page_post_update

Aprobación: ver la regla

Añade una actualización a una publicación de estado ya abierta, para contar cómo avanza el problema.

Lo que Claude pide
las fuentes no describen un comportamiento propio; se aplica la regla por defecto.
Cuándo sirve
el arreglo ya está desplegado y toca decir a los clientes que el servicio se está recuperando.
Ojo
elige bien la publicación; actualizar la de otro incidente confunde a todo el mundo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

create_team

Aprobación: ver la regla

Crea un equipo nuevo en la cuenta de PagerDuty.

Lo que Claude pide
no hay confirmación documentada para esta acción; rige la regla general.
Cuándo sirve
la empresa separa seguridad de infraestructura y cada uno necesita su equipo para ordenar servicios y guardias.
Ojo
un equipo recién creado no tiene miembros; hay que añadirlos después con otra herramienta.

Fuentegithub.com · 30 de septiembre de 2026 ↗

delete_alert_grouping_setting

Aprobación: ver la regla

Elimina un ajuste de agrupación de alertas de la cuenta.

Lo que Claude pide
ninguna fuente describe un paso de confirmación específico; aplica la regla general, y una supresión merece doble lectura.
Cuándo sirve
una agrupación antigua mezcla fallos distintos en un mismo incidente y el equipo decide quitarla.
Ojo
al borrarla, las alertas vuelven a abrir incidentes por separado y el ruido puede crecer de golpe.

Fuentegithub.com · 30 de septiembre de 2026 ↗

delete_team

Aprobación: ver la regla

Elimina un equipo de PagerDuty.

Lo que Claude pide
sin confirmación documentada propia; la cubre la aprobación por defecto de Claude.
Cuándo sirve
tras una reorganización queda un equipo vacío que ya no representa a nadie.
Ojo
antes de aprobar, comprueba qué servicios y calendarios dependían de ese equipo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

manage_incidents

Aprobación: ver la regla

Cambia el estado, la prioridad o las personas asignadas de un incidente, desde reconocerlo hasta resolverlo.

Lo que Claude pide
no hay una confirmación descrita para esta herramienta; se aplica la regla general de más abajo.
Cuándo sirve
le pides a Claude que reconozca el incidente, lo suba a prioridad alta y lo pase a quien lleva la base de datos.
Ojo
nombra bien el incidente y resuélvelo solo cuando el problema esté arreglado de verdad.

Fuentegithub.com · 30 de septiembre de 2026 ↗

remove_team_member

Aprobación: ver la regla

Quita a un usuario de un equipo de PagerDuty.

Lo que Claude pide
nada documentado en concreto; cubre la regla general de aprobaciones.
Cuándo sirve
alguien cambia de departamento y no debe seguir figurando en el equipo anterior.
Ojo
revisa si la persona sigue en algún calendario o escalado de ese equipo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

start_incident_workflow

Aprobación: ver la regla

Pone en marcha un flujo de trabajo de incidentes sobre un incidente concreto, con todos los pasos que ese flujo tenga configurados.

Lo que Claude pide
ninguna fuente detalla un aviso propio; rige la aprobación por defecto.
Cuándo sirve
el incidente pasa a crítico y quieres activar de golpe el protocolo de sala de crisis del equipo.
Ojo
un flujo puede avisar a gente y publicar mensajes; lee lo que hace antes de lanzarlo.

Fuentegithub.com · 30 de septiembre de 2026 ↗

update_alert_grouping_setting

Aprobación: ver la regla

Modifica un ajuste de agrupación de alertas que ya existe.

Lo que Claude pide
no consta una confirmación específica; aplica la regla general.
Cuándo sirve
la ventana de agrupación es demasiado corta y el mismo fallo sigue abriendo varios incidentes.
Ojo
el cambio afecta a todas las alertas futuras de ese ajuste; pruébalo en un servicio poco crítico si puedes.

Fuentegithub.com · 30 de septiembre de 2026 ↗

update_event_orchestration_router

Aprobación: ver la regla

Actualiza la configuración del enrutador de orquestación, el que reparte los eventos entre servicios.

Lo que Claude pide
las fuentes no describen un paso propio; se aplica la regla por defecto.
Cuándo sirve
reorganizas qué equipo recibe las alertas de cada sistema tras un cambio de estructura.
Ojo
tocar el enrutador afecta a todos los eventos entrantes; guarda antes una lectura de la configuración actual.

Fuentegithub.com · 30 de septiembre de 2026 ↗

update_schedule

Aprobación: ver la regla

Modifica un calendario de guardia existente.

Lo que Claude pide
sin confirmación documentada para esta herramienta; rige la regla general.
Cuándo sirve
el equipo pasa de turnos semanales a turnos de dos semanas y hay que rehacer la rotación.
Ojo
para un cambio puntual es mejor un reemplazo; tocar el calendario cambia todas las semanas siguientes.

Fuentegithub.com · 30 de septiembre de 2026 ↗

update_service

Aprobación: ver la regla

Cambia la configuración de un servicio.

Lo que Claude pide
no hay nada documentado para este caso; cuenta con la regla general de aprobaciones.
Cuándo sirve
un servicio pasa a manos de otro equipo y sus avisos deben llegar a la guardia nueva.
Ojo
un error aquí deja alertas sin destinatario; pide a Claude que te enseñe el antes y el después.

Fuentegithub.com · 30 de septiembre de 2026 ↗

update_team

Aprobación: ver la regla

Actualiza los datos de un equipo de PagerDuty.

Lo que Claude pide
ninguna fuente describe una confirmación propia; la cubre la aprobación por defecto.
Cuándo sirve
el equipo cambia de nombre tras la reorganización y quieres que PagerDuty lo refleje.
Ojo
la descripción de PagerDuty no detalla qué datos se pueden cambiar.

Fuentegithub.com · 30 de septiembre de 2026 ↗

Aprobaciones

Lo que Claude te consulta antes de actuar

Por defecto, Claude se detiene y te pide permiso antes de cada acción que hace en una cuenta en tu nombre. La petición aparece en la conversación, en el momento en que cuenta.

En un espacio Team o Enterprise, los propietarios deciden si un miembro puede dejar pasar ciertas acciones sin que se le vuelva a preguntar cada vez. También pueden limitar lo que un conector hace para toda la organización, por ejemplo dejar la lectura y cerrar la escritura. Ese ajuste se impone a todos y nadie lo salta desde su propia cuenta. Y Claude trabaja con tus permisos, nunca con más: actúa a través del acceso a PagerDuty que tú autorizaste. En plena crisis las peticiones llegan rápido, así que lee qué hace la acción antes de decir que sí.

Planes

En qué planes está disponible

De las 819 fichas del directorio oficial, ninguna muestra su disponibilidad por plan. La respuesta conector a conector no está publicada en ningún sitio: es un hueco real del catálogo.

La regla general sí está publicada: los conectores remotos están abiertos a todos los usuarios en Claude, Cowork, Claude Desktop y móvil, y las extensiones de escritorio se instalan en Claude Desktop. En Team y Enterprise, un Owner o un Primary Owner habilita el conector para la organización antes de que cada miembro pueda conectarse. Para ver el estado actualizado en tu cuenta, consulta la ficha del conector en el directorio oficial.

Límites

Dónde se detiene el conector Claude PagerDuty

Un conector no es una automatización. Claude llama a estas herramientas mientras te responde: nada arranca cuando suena una alerta, escala un incidente o empieza una guardia.

Esta página se apoya solo en la documentación de PagerDuty: ningún artículo de ayuda de Claude cubre este conector. La lista de herramientas es un mínimo observado, no una promesa, porque un administrador puede abrir acciones que ninguna ficha pública muestra. La insignia de socio del directorio tampoco es una auditoría de seguridad, y Anthropic lo avisa en cada ficha: no decide qué herramientas expone un fabricante ni garantiza que funcionen como se anuncia. Conecta solo lo que venga de un fabricante de confianza, aquí el propio PagerDuty. Para otro caso en el que las fuentes oficiales no coinciden, mira el conector Claude gmail.

Dos fuentes oficiales se contradicen

¿Qué lista de herramientas describe el conector PagerDuty que usa Claude?

Lo que sigue esta páginaLa ficha del directorio conserva los nombres de herramienta del servidor autoalojado, mientras que la base de conocimiento de PagerDuty de septiembre de 2026 describe herramientas agrupadas en el servidor alojado. Esta página toma la clasificación de lectura o escritura de cada herramienta de la tabla archivada, la única fuente que cubre estos nombres exactos. Lo que manda para tu cuenta es la lista que muestra el conector una vez conectado.

¿Necesitas ayuda?

¿Necesitas ayuda para conectar PagerDuty con Claude?

Una persona lee cada mensaje.

FAQ

Preguntas frecuentes sobre el conector Claude PagerDuty

01¿Qué puede hacer Claude con el conector Claude PagerDuty?
Claude puede seguir y gestionar tus incidentes de PagerDuty desde la conversación. El directorio enumera 64 herramientas: 42 leen incidentes, alertas, notas, calendarios, guardias, servicios, orquestaciones, páginas de estado, equipos y usuarios, y 22 abren incidentes, suman intervinientes, cambian estado y prioridad, retocan calendarios y servicios, publican en páginas de estado o borran ajustes. En la práctica, puedes preguntarle quién está de guardia, qué se ha probado en un incidente abierto o pedirle que cubra un turno esta noche.
02¿Puede Claude abrir, resolver o borrar cosas en PagerDuty?
Sí, veintidós herramientas documentadas modifican tu cuenta. Claude puede crear incidentes, cambiar su estado, su prioridad o a quién están asignados, añadir notas e intervinientes, lanzar flujos de incidente, crear o retocar calendarios, reemplazos, servicios y equipos, publicar en una página de estado y ajustar reglas de enrutado. Dos herramientas borran: una elimina un ajuste de agrupación de alertas y la otra un equipo. La regla de aprobación por defecto de Claude las cubre todas, y Claude solo tiene los permisos de la persona que conectó PagerDuty.
03¿Claude me pregunta antes de avisar a alguien en PagerDuty?
Por defecto, sí: Claude pide confirmación antes de cada acción que hace en una cuenta en tu nombre. Ninguna fuente describe una confirmación propia de alguna herramienta de PagerDuty, así que esa regla general es la que cubre los incidentes nuevos, los intervinientes añadidos y los flujos lanzados. En Team y Enterprise, los propietarios deciden si los miembros pueden saltarse ciertas confirmaciones y pueden dejar el conector en solo lectura. Por parte de PagerDuty, un cliente OAuth con alcance limitado restringe qué herramientas se completan.
04¿En qué planes está disponible?
Ninguna fuente oficial publica la disponibilidad por plan conector a conector, y ninguna de las 819 fichas del directorio la muestra. La regla general dice que los conectores remotos están abiertos a todos los usuarios en Claude, Cowork, Claude Desktop y móvil. En Team y Enterprise, un Owner o un Primary Owner activa el conector para la organización antes de que los miembros se conecten uno a uno. La ficha del directorio es el único sitio que enseña el estado actualizado para tu cuenta.
05¿Claude ve toda nuestra cuenta de PagerDuty?
Claude llega hasta donde llega el acceso a PagerDuty que autorizaste, y ni un paso más. PagerDuty añade que algunas herramientas y filtros exigen acceso a nivel de usuario, así que una conexión con credenciales de cuenta puede no responder igual a todas las preguntas. Un cliente OAuth con alcance limitado, en el lado de PagerDuty, puede reducir las herramientas que se completan. En el lado de Claude, un propietario de un espacio Team o Enterprise puede restringir el conector para todos, y ningún miembro puede levantar ese límite.
06¿Por qué las herramientas de PagerDuty en Claude no coinciden con la documentación de PagerDuty?
Porque conviven dos listas oficiales. La ficha del directorio muestra 64 nombres de herramienta detallados que corresponden al servidor autoalojado de PagerDuty, que el fabricante ha archivado. La base de conocimiento actual de PagerDuty describe su servidor alojado con herramientas agrupadas, una para consultar y otra para gestionar cada ámbito. Esta página sigue los nombres del directorio y toma su clasificación de la tabla archivada de PagerDuty. Revisa la lista que muestra tu cuenta conectada para saber qué tienes de verdad.
07¿Claude o una herramienta de automatización para PagerDuty?
No hacen el mismo trabajo, así que depende del uso. Claude trabaja dentro de una conversación: preguntas por un incidente, él llama a una herramienta, tú apruebas y compruebas el resultado. Una herramienta de automatización corre en segundo plano cuando ocurre algo, por ejemplo un incidente nuevo que debe abrir un ticket en otra aplicación. El conector no tiene ninguna herramienta que arranque sola. Para enlazar sus eventos con otras aplicaciones, lo adecuado es una plataforma de automatización.