Ressources · Connecteur Claude

Connecteur Claude PagerDutyCe que Claude sait faire dans ton compte PagerDuty.

Le connecteur Claude PagerDuty expose 64 outils. 42 lisent incidents, alertes, plannings, services et pages de statut, 22 peuvent ouvrir des incidents, ajouter des intervenants, retoucher des rotations ou supprimer des réglages. Ici : ce que fait chacun, ce que tu approuves, et quelle doc croire.

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Aperçu

Ce que ça change d'ouvrir PagerDuty à Claude

En plein incident, personne n'a envie de traverser cinq écrans pour savoir qui est d'astreinte ou ce qui a déjà été tenté. Tu poses la question à Claude, il lit incidents, notes, plannings et événements de changement dans PagerDuty pendant qu'il te répond, et il peut faire l'étape suivante une fois que tu l'approuves.

Reprendre le fil au milieu de la nuit. list_incidents montre ce qui est ouvert, list_incident_notes ce que les intervenants ont déjà tenté, et get_past_incidents ou get_related_incidents si c'est déjà arrivé ou si d'autres équipes sont touchées.

Agir sans quitter la conversation. manage_incidents change le statut, la priorité ou les personnes attribuées, add_responders ajoute des intervenants, add_note_to_incident consigne ce que tu as fait, et create_status_page_post publie un avis sur une page de statut.

Tenir le planning. list_oncalls répond à « qui est d'astreinte là, maintenant ? », et create_schedule_override couvre la garde d'un collègue malade en une phrase.

Voilà ce que la fiche du répertoire ne dit pas. Ses 64 noms d'outils viennent du serveur auto-hébergé de PagerDuty, que l'éditeur a depuis archivé ; son serveur hébergé actuel documente des outils regroupés. On l'explique plus bas. Rien ne tourne seul non plus : aucun outil ne se déclenche quand une alerte arrive. Pour relier ses événements à d'autres applications, regarde l'intégration PagerDuty n8n ou l'intégration PagerDuty Make.

Vocabulaire

Le vocabulaire en une minute

Cinq mots que tu vas croiser en branchant PagerDuty sur Claude.

Connecteur
Le lien que tu poses une fois entre Claude et un compte que tu as déjà, pour qu'il puisse y travailler pendant qu'il te répond.
Outil
Une action nommée que le connecteur ouvre à Claude. Il choisit seul celles dont il a besoin ; le répertoire les liste par leur nom.
Autorisation
L'écran de connexion du service lui-même, où tu confies à Claude l'accès qu'il utilisera. Donnée une fois par personne, reprise quand tu veux.
Approbation
La confirmation que Claude attend avant d'aller au bout d'une action qui modifie ton compte, affichée dans la conversation au bon moment.
MCP
Le standard commun sur lequel reposent les connecteurs : c'est lui qui permet à un assistant comme Claude de dialoguer avec un service extérieur.
Connexion

Brancher PagerDuty à Claude en trois étapes

  1. 01

    Retrouver PagerDuty dans Claude

    Dans Claude, ouvre Customize puis Connectors et repère PagerDuty dans la liste. Sur un espace Team ou Enterprise, un Owner ou un Primary Owner doit d'abord activer le connecteur pour que chaque membre puisse s'y connecter.

  2. 02

    Lancer le branchement

    Clique sur Connect depuis sa ligne, puis identifie-toi sur PagerDuty dans la fenêtre que PagerDuty ouvre lui-même. Si le lien casse un jour, passe par Disconnect et rebranche depuis le même endroit.

  3. 03

    Relire l'écran d'autorisation

    Lis l'écran d'autorisation de PagerDuty avant de valider. Il appartient à PagerDuty, pas à Claude, et c'est lui qui fixe ce que l'accès couvre. Tu peux retirer cet accès plus tard depuis ton compte PagerDuty.

Outils

Les 64 outils du connecteur Claude PagerDuty, rangés par usage

PagerDuty donne à Claude 64 outils : 42 qui lisent ton compte, 22 qui y changent quelque chose.

Deux groupes : ce que Claude lit et ce qu'il peut changer. Le classement lecture ou écriture vient du propre tableau d'outils de PagerDuty pour ces noms exacts. Les noms restent ceux que Claude affiche.

  • 42 lecture
  • 22 écriture

Ce que Claude lit (42)

42 outils

Quarante-deux outils qui consultent incidents, alertes, plannings, services, orchestrations, pages de statut, équipes et utilisateurs.

get_alert_from_incident

Ouvre une alerte précise rattachée à un incident, le signal brut qui est derrière.

Quand ça sert
un incident regroupe plusieurs alertes et tu veux savoir laquelle s'est déclenchée en premier.
Attention
Claude a besoin de l'incident et de l'alerte à examiner.

Sourcegithub.com · 30 septembre 2026 ↗

get_alert_grouping_setting

Montre un réglage de regroupement d'alertes, la règle qui décide quelles alertes atterrissent ensemble dans un même incident.

Quand ça sert
l'équipe reçoit dix incidents pour une seule panne et tu veux voir comment le regroupement est réglé.
Attention
lire le réglage ne dit rien de son efficacité réelle.

Sourcegithub.com · 30 septembre 2026 ↗

get_change_event

Récupère l'un des événements que PagerDuty consigne quand quelqu'un touche à un service, comme une mise en production, avec son détail.

Quand ça sert
un incident a démarré juste après une mise en production et tu veux la trace exacte de celle-ci.
Attention
il porte sur un seul événement ; les outils de liste donnent la vue d'ensemble.

Sourcegithub.com · 30 septembre 2026 ↗

get_escalation_policy

Renvoie une politique d'escalade précise, la chaîne de personnes que PagerDuty appelle quand le premier intervenant ne répond pas.

Quand ça sert
tu veux savoir qui sera appelé ensuite si l'astreinte de cette nuit rate une alerte.
Attention
une politique montre des niveaux et des cibles, pas qui est d'astreinte à l'instant.

Sourcegithub.com · 30 septembre 2026 ↗

get_event_orchestration

Lit une orchestration d'événements précise, la logique d'aiguillage que PagerDuty applique aux événements entrants.

Quand ça sert
une intégration bavarde réveille toujours la mauvaise équipe et tu veux voir l'orchestration derrière.
Attention
le routeur, les règles de service et les règles globales ont chacun leur outil.

Sourcegithub.com · 30 septembre 2026 ↗

get_event_orchestration_global

Rapporte les règles globales d'une orchestration, celles qui s'appliquent à chaque événement avant tout aiguillage.

Quand ça sert
tu soupçonnes une règle globale d'écarter certains événements sans bruit.
Attention
ces règles touchent tout ce qui entre, lis-les avec soin avant de proposer quoi que ce soit.

Sourcegithub.com · 30 septembre 2026 ↗

get_event_orchestration_router

Affiche la configuration du routeur d'une orchestration, la partie qui décide vers quel service part chaque événement.

Quand ça sert
les événements d'un nouvel outil de supervision atterrissent sur le mauvais service et tu veux comprendre pourquoi.
Attention
seul le routeur apparaît ici, pas les règles que chaque service applique ensuite.

Sourcegithub.com · 30 septembre 2026 ↗

get_event_orchestration_service

Ramène les règles d'orchestration propres à un service, appliquées une fois l'événement aiguillé vers lui.

Quand ça sert
tu veux savoir pourquoi les événements mineurs du service de paiement réveillent encore quelqu'un.
Attention
nomme le service clairement, beaucoup se ressemblent dans les gros comptes.

Sourcegithub.com · 30 septembre 2026 ↗

get_incident

Remonte un incident par son identifiant, avec les détails que les intervenants regardent en premier.

Quand ça sert
tu rejoins l'appel en retard et tu veux un résumé de l'incident dont tout le monde parle.
Attention
il faut l'identifiant de l'incident ou assez de contexte pour que Claude le retrouve.

Sourcegithub.com · 30 septembre 2026 ↗

get_incident_workflow

Présente le détail d'un workflow d'incident, une suite d'étapes prédéfinies que PagerDuty peut dérouler pendant un incident.

Quand ça sert
avant un exercice, tu veux vérifier ce que fait vraiment le workflow d'incident majeur.
Attention
le consulter ne lance rien ; démarrer un workflow relève d'un autre outil.

Sourcegithub.com · 30 septembre 2026 ↗

get_log_entry

Récupère une seule entrée du journal, la piste d'audit de ce qui s'est passé dans le compte.

Quand ça sert
tu veux savoir qui a exactement pris en charge un incident à 3 h du matin.
Attention
Claude doit savoir de quelle entrée tu parles, en général après la liste.

Sourcegithub.com · 30 septembre 2026 ↗

get_outlier_incident

Fournit l'analyse d'anomalie de PagerDuty pour un incident, qui dit s'il sort de l'ordinaire par rapport aux précédents.

Quand ça sert
tu veux savoir si l'alerte base de données de cette nuit est banale ou inédite.
Attention
l'analyse est celle de PagerDuty, Claude ne fait que la rapporter.

Sourcegithub.com · 30 septembre 2026 ↗

get_past_incidents

Retrouve des incidents passés semblables à un incident donné, pour réutiliser ce qui a marché la dernière fois.

Quand ça sert
la même erreur est de retour et tu veux savoir comment l'équipe l'avait réglée.
Attention
semblable ne veut pas dire identique, relis les anciennes notes avant de reprendre un correctif.

Sourcegithub.com · 30 septembre 2026 ↗

get_schedule

Ouvre un planning d'astreinte précis, pour que Claude t'explique la rotation simplement.

Quand ça sert
tu veux voir à quoi ressemble la rotation de l'équipe plateforme le mois prochain.
Attention
un planning est le plan prévu ; la liste des astreintes en cours est un autre outil.

Sourcegithub.com · 30 septembre 2026 ↗

get_service

Donne le détail d'un service précis, l'unité à laquelle PagerDuty rattache alertes et incidents, avec sa configuration actuelle.

Quand ça sert
tu veux savoir quelle politique d'escalade utilise le service de paiement.
Attention
nomme le service exactement, les noms proches sont courants.

Sourcegithub.com · 30 septembre 2026 ↗

get_status_page_post

Lit une publication d'une page de statut, l'avis public ou interne sur un incident ou une maintenance.

Quand ça sert
un client cite ta page de statut et tu veux la formulation exacte qui a été publiée.
Attention
il lit la publication, pas les messages de suivi qui s'y rattachent.

Sourcegithub.com · 30 septembre 2026 ↗

get_team

Présente une équipe PagerDuty précise et son détail, le groupe qui porte services, plannings et politiques d'escalade dans ton compte.

Quand ça sert
tu veux vérifier comment l'équipe base de données est organisée avant de lui confier un nouveau service.
Attention
la composition de l'équipe a son propre outil de liste.

Sourcegithub.com · 30 septembre 2026 ↗

get_user_data

Récupère les informations de l'utilisateur connecté, autrement dit toi tel que PagerDuty te voit.

Quand ça sert
Claude doit savoir qui pose la question avant de filtrer les incidents qui te sont attribués.
Attention
d'après PagerDuty, certains filtres, comme les incidents qui te sont attribués, exigent un accès au niveau utilisateur.

Sourcegithub.com · 30 septembre 2026 ↗

list_alert_grouping_settings

Liste tous les réglages de regroupement d'alertes du compte.

Quand ça sert
tu fais la chasse au bruit des alertes et tu veux la vue complète des regroupements configurés.
Attention
une longue liste se lit mieux si tu poses la question service par service.

Sourcegithub.com · 30 septembre 2026 ↗

list_alerts_from_incident

Liste les alertes qui appartiennent à un incident, les signaux individuels regroupés sous lui.

Quand ça sert
un incident est ouvert depuis une heure et tu veux savoir combien d'alertes il a avalées.
Attention
donne l'incident à Claude, il liste les alertes incident par incident.

Sourcegithub.com · 30 septembre 2026 ↗

list_change_events

Liste les événements que PagerDuty consigne sur tous les services quand quelque chose est livré ou retouché.

Quand ça sert
tu veux savoir ce qui a été livré dans l'heure qui précède un pic d'erreurs.
Attention
un compte actif renvoie beaucoup, donne une fenêtre de temps.

Sourcegithub.com · 30 septembre 2026 ↗

list_escalation_policies

Liste toutes les politiques d'escalade du compte.

Quand ça sert
tu veux trouver les services encore rattachés à la politique d'une équipe qui n'existe plus.
Attention
la liste ne dit pas qui est d'astreinte maintenant, seulement comment l'appel monte de niveau en niveau.

Sourcegithub.com · 30 septembre 2026 ↗

list_event_orchestrations

Liste les orchestrations d'événements de ton compte, chacune étant un jeu de règles d'aiguillage pour les événements entrants.

Quand ça sert
tu arrives dans l'équipe et tu veux l'inventaire de l'aiguillage des événements.
Attention
ouvre une orchestration pour ses règles ; la liste donne les noms et identifiants.

Sourcegithub.com · 30 septembre 2026 ↗

list_incident_change_events

Renvoie les événements de service que PagerDuty relie à un incident donné, comme les mises en production juste avant son début.

Quand ça sert
tu veux savoir si une livraison a eu lieu peu avant la panne.
Attention
un lien est un indice, pas une preuve de cause.

Sourcegithub.com · 30 septembre 2026 ↗

list_incident_notes

Liste les notes laissées sur un incident par les intervenants.

Quand ça sert
tu reprends un incident en fin de garde d'un collègue et tu veux la chronologie de ce qui a été tenté.
Attention
les notes ne valent que ce que les intervenants ont pris la peine de consigner.

Sourcegithub.com · 30 septembre 2026 ↗

list_incident_workflows

Liste les workflows d'incident disponibles dans ton compte, ces séquences de réponse toutes prêtes que tes admins ont préparées pour les incidents graves.

Quand ça sert
tu veux savoir quels workflows existent avant un exercice d'incident majeur, et comment chacun s'appelle.
Attention
les lister ne déclenche rien.

Sourcegithub.com · 30 septembre 2026 ↗

list_incidents

Filtre les incidents du compte, la façon principale de demander ce qui se passe maintenant ou ce qui s'est passé la semaine dernière.

Quand ça sert
lundi matin, tu veux tous les incidents de haute urgence du week-end.
Attention
PagerDuty précise que filtrer par équipe ou par personne attribuée demande un accès au niveau utilisateur.

Sourcegithub.com · 30 septembre 2026 ↗

list_log_entries

Liste les entrées du journal, la piste d'audit des actions menées dans le compte.

Quand ça sert
après une revue d'incident, tu veux la séquence de qui a pris en charge, escaladé et résolu quoi.
Attention
la piste peut être longue, donne à Claude un incident ou une période.

Sourcegithub.com · 30 septembre 2026 ↗

list_oncalls

Montre les astreintes en cours dans tout le compte.

Quand ça sert
une escalade client vient de tomber et il te faut le nom de l'astreinte paiements tout de suite.
Attention
il reflète l'état présent, tel que PagerDuty le rapporte.

Sourcegithub.com · 30 septembre 2026 ↗

list_schedule_users

Liste les utilisateurs d'un planning sur une période donnée.

Quand ça sert
tu prépares les congés et tu veux savoir qui couvre la dernière semaine de décembre.
Attention
donne une plage de dates précise, sinon la réponse devient difficile à lire.

Sourcegithub.com · 30 septembre 2026 ↗

list_schedules

Recense les plannings d'astreinte de ton compte, les rotations qui décident qui est appelé, de jour comme de nuit.

Quand ça sert
tu veux l'inventaire de toutes les rotations avant de réorganiser les équipes le trimestre prochain.
Attention
le détail de chaque planning vient de l'outil dédié à un planning.

Sourcegithub.com · 30 septembre 2026 ↗

list_service_change_events

Sort les événements de livraison et de retouche consignés pour un service précis, un moyen rapide de voir ce qui a bougé récemment.

Quand ça sert
le service de recherche a ralenti cet après-midi et tu veux ce qui y a été livré aujourd'hui.
Attention
nomme le service exactement.

Sourcegithub.com · 30 septembre 2026 ↗

list_services

Dresse la liste des services de ton compte PagerDuty, chacun étant une unité qui reçoit des alertes et ouvre des incidents.

Quand ça sert
tu veux repérer les services sans équipe propriétaire avant un audit.
Attention
les gros comptes ont beaucoup de services, demande un filtre ou une équipe.

Sourcegithub.com · 30 septembre 2026 ↗

list_status_page_impacts

Liste les options d'impact d'une page de statut, les libellés que tu choisis pour dire à quel point un incident est grave.

Quand ça sert
tu rédiges un avis et tu veux les libellés d'impact exacts que propose ta page.
Attention
ce sont des options, pas des incidents en cours.

Sourcegithub.com · 30 septembre 2026 ↗

list_status_page_post_updates

Liste dans l'ordre les messages de suivi publiés sous une publication de page de statut.

Quand ça sert
tu veux la chronologie complète que tes clients ont vue pendant la panne d'hier.
Attention
il lit ce qui a été publié ; ajouter un message relève d'un autre outil, soumis à approbation.

Sourcegithub.com · 30 septembre 2026 ↗

list_status_page_severities

Liste les niveaux de gravité configurés pour une page de statut, l'échelle qu'utilisent tes avis pour dire à quel point un incident est sérieux.

Quand ça sert
tu veux t'assurer que l'avis reprend la gravité convenue avec l'équipe.
Attention
les gravités varient d'une page de statut à l'autre.

Sourcegithub.com · 30 septembre 2026 ↗

list_status_page_statuses

Énumère les options de statut d'une page de statut, les états possibles d'un avis d'incident.

Quand ça sert
tu prépares un avis et tu veux la formulation de statut exacte disponible.
Attention
ce sont des choix possibles, pas l'état en direct.

Sourcegithub.com · 30 septembre 2026 ↗

list_status_pages

Rassemble les pages de statut de ton compte, publiques ou internes, avec les noms que voient tes clients ou tes collègues.

Quand ça sert
tu tiens une page publique et une interne et tu veux être sûr de laquelle est laquelle.
Attention
les publications de chaque page viennent d'autres outils.

Sourcegithub.com · 30 septembre 2026 ↗

list_team_members

Liste les membres d'une équipe, les personnes que PagerDuty regroupe sous elle pour ses services et plannings.

Quand ça sert
tu veux vérifier qui fait partie de l'équipe SRE avant de lui attribuer un nouveau service.
Attention
il montre la composition, pas qui est d'astreinte ce soir.

Sourcegithub.com · 30 septembre 2026 ↗

list_teams

Passe en revue les équipes de ton compte PagerDuty, les groupes qui portent services, plannings et politiques d'escalade.

Quand ça sert
tu réorganises les astreintes et tu veux d'abord tous les noms d'équipes au même endroit.
Attention
ouvre une équipe pour son détail.

Sourcegithub.com · 30 septembre 2026 ↗

list_users

Donne la liste des utilisateurs du compte, les personnes qui peuvent être appelées ou qui se connectent à PagerDuty.

Quand ça sert
tu veux repérer les comptes de personnes qui ont quitté l'entreprise.
Attention
il liste des personnes, il ne détaille pas leurs permissions.

Sourcegithub.com · 30 septembre 2026 ↗

Ce que Claude peut changer (22)

22 outils

Vingt-deux outils qui ouvrent, ajoutent, retouchent, publient ou suppriment. Aucune source ne précise leur confirmation : la règle générale plus bas s'applique.

add_note_to_incident

Approbation : voir la règle

Ajoute une note à un incident, le journal de bord que partagent les intervenants.

Ce que Claude demande
aucune source ne décrit de confirmation propre à cet outil, c'est donc la règle générale des approbations qui joue.
Quand ça sert
tu veux que Claude consigne ce que tu viens de tenter pour que le suivant ne le refasse pas.
Attention
les notes restent sur l'incident pour le retour d'expérience, garde-les factuelles.

Sourcegithub.com · 30 septembre 2026 ↗

add_responders

Approbation : voir la règle

Fait entrer des intervenants supplémentaires dans la réponse à un incident.

Ce que Claude demande
rien de précis n'est documenté ici, reporte-toi à la règle générale plus bas.
Quand ça sert
l'équipe base de données doit rejoindre tout de suite une panne du paiement.
Attention
vérifie les noms des personnes ajoutées avant d'approuver.

Sourcegithub.com · 30 septembre 2026 ↗

add_team_member

Approbation : voir la règle

Inscrit un utilisateur dans une équipe.

Ce que Claude demande
aucune confirmation dédiée n'est décrite, la règle d'approbation par défaut le couvre.
Quand ça sert
un nouvel ingénieur rejoint l'équipe plateforme et doit apparaître dans la préparation des rotations.
Attention
rejoindre une équipe peut l'entraîner dans les escalades de celle-ci.

Sourcegithub.com · 30 septembre 2026 ↗

append_event_orchestration_router_rule

Approbation : voir la règle

Ajoute une règle au routeur d'une orchestration, ce qui change la destination de certains événements entrants.

Ce que Claude demande
aucune confirmation propre n'est décrite ; la règle générale s'applique.
Quand ça sert
les événements d'un nouvel outil de supervision doivent atteindre le service paiement.
Attention
une mauvaise règle peut envoyer des alertes aux mauvaises personnes, teste-la un jour calme.

Sourcegithub.com · 30 septembre 2026 ↗

create_alert_grouping_setting

Approbation : voir la règle

Crée un réglage de regroupement d'alertes, une règle pour réunir les alertes en moins d'incidents.

Ce que Claude demande
rien de propre à cet outil n'est documenté, la règle générale de la section approbations tient.
Quand ça sert
une seule panne produit vingt incidents et tu veux qu'ils soient regroupés la prochaine fois.
Attention
regrouper trop large peut masquer un second problème sans rapport.

Sourcegithub.com · 30 septembre 2026 ↗

create_incident

Approbation : voir la règle

Crée un nouvel incident dans PagerDuty.

Ce que Claude demande
aucune source ne décrit de confirmation pour lui ; la règle par défaut le couvre.
Quand ça sert
un client signale un bug que ta supervision a raté et tu veux l'astreinte dessus.
Attention
vérifie le service et la formulation avant d'approuver.

Sourcegithub.com · 30 septembre 2026 ↗

create_schedule

Approbation : voir la règle

Met en place un planning d'astreinte.

Ce que Claude demande
aucune source ne décrit de confirmation propre à cet outil, c'est donc la règle générale des approbations qui joue.
Quand ça sert
une nouvelle équipe prend les nuits à partir du mois prochain.
Attention
vérifie le fuseau horaire et le début de rotation avant d'approuver.

Sourcegithub.com · 30 septembre 2026 ↗

create_schedule_override

Approbation : voir la règle

Pose un remplacement sur un planning, un échange temporaire de la personne d'astreinte.

Ce que Claude demande
rien de précis n'est documenté ici, reporte-toi à la règle générale plus bas.
Quand ça sert
une collègue est malade ce soir et tu prends sa garde.
Attention
un remplacement passe devant la rotation normale, vérifie les heures exactes.

Sourcegithub.com · 30 septembre 2026 ↗

create_service

Approbation : voir la règle

Enregistre un nouveau service dans PagerDuty, l'unité qui recevra les alertes.

Ce que Claude demande
aucune confirmation dédiée n'est décrite, la règle d'approbation par défaut le couvre.
Quand ça sert
l'équipe livre une nouvelle API et veut des alertes dessus dès le premier jour.
Attention
précise l'équipe et la politique d'escalade qu'il doit utiliser.

Sourcegithub.com · 30 septembre 2026 ↗

create_status_page_post

Approbation : voir la règle

Publie un avis sur une page de statut, celui que lisent tes clients ou tes collègues.

Ce que Claude demande
aucune confirmation propre n'est décrite ; la règle générale s'applique.
Quand ça sert
une panne est confirmée et tu veux un premier avis en ligne rapidement.
Attention
sur une page publique, tout le monde le voit, relis la formulation avant d'approuver.

Sourcegithub.com · 30 septembre 2026 ↗

create_status_page_post_update

Approbation : voir la règle

Ajoute un message de suivi à une publication de page de statut existante.

Ce que Claude demande
rien de propre à cet outil n'est documenté, la règle générale de la section approbations tient.
Quand ça sert
le correctif est déployé et tu veux dire aux clients que le service se rétablit.
Attention
chaque message de suivi est public sur une page publique.

Sourcegithub.com · 30 septembre 2026 ↗

create_team

Approbation : voir la règle

Ajoute une toute nouvelle équipe à PagerDuty.

Ce que Claude demande
aucune source ne décrit de confirmation pour lui ; la règle par défaut le couvre.
Quand ça sert
une réorganisation coupe l'équipe plateforme en deux.
Attention
membres et services restent à rattacher ensuite.

Sourcegithub.com · 30 septembre 2026 ↗

delete_alert_grouping_setting

Approbation : voir la règle

Supprime un réglage de regroupement d'alertes.

Ce que Claude demande
aucune source ne décrit de confirmation propre à cet outil, c'est donc la règle générale des approbations qui joue.
Quand ça sert
une vieille règle fusionne des alertes sans rapport et tu veux t'en débarrasser.
Attention
sans elle, les alertes qu'elle réunissait reviennent en incidents séparés.

Sourcegithub.com · 30 septembre 2026 ↗

delete_team

Approbation : voir la règle

Retire une équipe de ton compte.

Ce que Claude demande
rien de précis n'est documenté ici, reporte-toi à la règle générale plus bas.
Quand ça sert
une équipe dissoute depuis des mois encombre encore la liste.
Attention
vérifie d'abord quels services et politiques pointent encore vers elle.

Sourcegithub.com · 30 septembre 2026 ↗

manage_incidents

Approbation : voir la règle

Change le statut, la priorité ou les personnes attribuées d'un incident, par exemple pour le prendre en charge, le résoudre ou le réattribuer.

Ce que Claude demande
aucune confirmation dédiée n'est décrite, la règle d'approbation par défaut le couvre.
Quand ça sert
le correctif est confirmé et tu veux l'incident résolu avec la bonne priorité pour le rapport.
Attention
résoudre le mauvais incident ferme un problème encore actif, nomme-le clairement.

Sourcegithub.com · 30 septembre 2026 ↗

remove_team_member

Approbation : voir la règle

Retire un utilisateur d'une équipe.

Ce que Claude demande
aucune confirmation propre n'est décrite ; la règle générale s'applique.
Quand ça sert
un ingénieur est passé dans un autre service et doit quitter l'effectif de l'équipe.
Attention
vérifie s'il figure encore dans un planning ou une escalade de cette équipe.

Sourcegithub.com · 30 septembre 2026 ↗

start_incident_workflow

Approbation : voir la règle

Déclenche un workflow d'incident, qui déroule ses étapes prédéfinies sur un incident.

Ce que Claude demande
rien de propre à cet outil n'est documenté, la règle générale de la section approbations tient.
Quand ça sert
un incident majeur est déclaré et ton workflow ouvre la cellule de crise et prévient les parties prenantes.
Attention
un workflow peut appeler ou prévenir beaucoup de monde d'un coup, sache ce qu'il fait avant de le lancer.

Sourcegithub.com · 30 septembre 2026 ↗

update_alert_grouping_setting

Approbation : voir la règle

Modifie un réglage de regroupement d'alertes.

Ce que Claude demande
aucune source ne décrit de confirmation pour lui ; la règle par défaut le couvre.
Quand ça sert
la fenêtre de regroupement est trop courte et des alertes liées se dispersent encore en plusieurs incidents.
Attention
la nouvelle règle s'applique aux alertes futures, teste-la avant une période chargée.

Sourcegithub.com · 30 septembre 2026 ↗

update_event_orchestration_router

Approbation : voir la règle

Réécrit le routeur d'une orchestration d'événements, qui décide où vont les événements entrants.

Ce que Claude demande
aucune source ne décrit de confirmation propre à cet outil, c'est donc la règle générale des approbations qui joue.
Quand ça sert
l'aiguillage pointe encore vers un service retiré.
Attention
une erreur de routeur peut rendre muettes les alertes de tout un service.

Sourcegithub.com · 30 septembre 2026 ↗

update_schedule

Approbation : voir la règle

Met à jour un planning d'astreinte existant.

Ce que Claude demande
rien de précis n'est documenté ici, reporte-toi à la règle générale plus bas.
Quand ça sert
l'équipe passe de rotations hebdomadaires à des rotations de quinze jours.
Attention
les gens organisent leur vie autour de l'astreinte, annonce le changement.

Sourcegithub.com · 30 septembre 2026 ↗

update_service

Approbation : voir la règle

Actualise la configuration d'un service.

Ce que Claude demande
aucune confirmation dédiée n'est décrite, la règle d'approbation par défaut le couvre.
Quand ça sert
le service de paiement doit désormais appeler via la politique d'escalade de l'équipe paiements.
Attention
une mauvaise politique d'escalade réveille les mauvaises personnes.

Sourcegithub.com · 30 septembre 2026 ↗

update_team

Approbation : voir la règle

Édite le détail d'une équipe.

Ce que Claude demande
aucune confirmation propre n'est décrite ; la règle générale s'applique.
Quand ça sert
l'équipe a changé de nom et PagerDuty doit suivre.
Attention
la description d'une ligne de PagerDuty ne dit pas quels détails peuvent bouger.

Sourcegithub.com · 30 septembre 2026 ↗

Approbations

Ce que Claude te demande avant d'agir

Par défaut, Claude s'arrête et demande ton accord avant chaque action qu'il mène sur un compte à ta place. La demande apparaît dans la conversation, au moment où elle compte.

Sur un espace Team ou Enterprise, les propriétaires décident si un membre peut laisser passer certaines actions sans qu'on les lui redemande à chaque fois. Ils peuvent aussi borner ce qu'un connecteur a le droit de faire pour toute l'organisation, en gardant la lecture et en fermant l'écriture par exemple. Ce réglage s'impose à tous, personne ne le contourne depuis son compte. Enfin, Claude travaille avec tes droits et rien de plus : il agit par l'accès PagerDuty que tu as autorisé. En incident, les demandes arrivent vite ; regarde ce que fait l'action avant de dire oui.

Plans

Sur quels plans c'est disponible

Sur les 819 fiches du répertoire officiel, aucune n'affiche de disponibilité par plan. La réponse connecteur par connecteur n'est publiée nulle part : c'est un vrai trou du catalogue.

La règle générale, elle, est publiée : les connecteurs distants sont ouverts à tous les utilisateurs sur Claude, Cowork, Claude Desktop et mobile, et les extensions de bureau s'installent sur Claude Desktop. Sur Team et Enterprise, un Owner ou un Primary Owner ouvre le connecteur pour l'organisation avant que chaque membre puisse s'y connecter. Pour l'état à jour sur ton compte, c'est la fiche du connecteur dans le répertoire officiel qu'il faut consulter.

Limites

Là où le connecteur Claude PagerDuty s'arrête

Un connecteur n'est pas une automatisation. Claude appelle ces outils pendant qu'il te répond : rien ne démarre quand une alerte sonne, qu'un incident escalade ou qu'une garde commence.

Cette page repose sur la seule documentation de PagerDuty : aucun article d'aide de Claude ne couvre ce connecteur. La liste d'outils est un plancher observé, pas une promesse, puisqu'un administrateur peut ouvrir des actions qu'aucune fiche publique ne montre. Le badge partenaire du répertoire n'est pas non plus un audit de sécurité, et Anthropic l'écrit sur chaque fiche : il ne choisit pas les outils qu'un éditeur expose et ne garantit pas qu'ils se comportent comme annoncé. Ne branche que ce qui vient d'un éditeur de confiance, ici PagerDuty lui-même. Pour un autre cas où les sources officielles divergent, vois le connecteur Claude gmail.

Deux sources officielles se contredisent

Quelle liste d'outils décrit le connecteur PagerDuty qu'utilise Claude ?

Ce que cette page retientLa fiche du répertoire porte encore les noms d'outils du serveur auto-hébergé, alors que la base de connaissances de PagerDuty de septembre 2026 décrit des outils regroupés sur le serveur hébergé. Cette page prend le classement lecture ou écriture de chaque outil dans le tableau archivé, seule source qui couvre ces noms exacts. Ce qui compte pour ton compte, c'est la liste qu'affiche le connecteur une fois branché.

Besoin d'aide

Besoin d'aide pour brancher PagerDuty sur Claude ?

Une personne lit chaque message.

FAQ

Questions fréquentes sur le connecteur Claude PagerDuty

01Que peut faire Claude avec le connecteur Claude PagerDuty ?
Claude peut suivre et traiter tes incidents PagerDuty depuis la conversation. Le répertoire liste 64 outils : 42 lisent incidents, alertes, notes, plannings, astreintes, services, orchestrations, pages de statut, équipes et utilisateurs, 22 ouvrent des incidents, ajoutent des intervenants, gèrent statut et priorité, retouchent plannings et services, publient sur les pages de statut ou suppriment des réglages. Concrètement, tu peux demander qui est d'astreinte, ce qui a été tenté sur un incident ouvert, ou un remplacement pour ce soir.
02Claude peut-il ouvrir, résoudre ou supprimer dans PagerDuty ?
Oui, vingt-deux outils documentés modifient ton compte. Claude peut créer des incidents, gérer leur statut, leur priorité ou les personnes attribuées, ajouter notes et intervenants, lancer des workflows d'incident, créer ou retoucher plannings, remplacements, services et équipes, publier sur une page de statut et retoucher des règles d'aiguillage. Deux outils suppriment : l'un un réglage de regroupement d'alertes, l'autre une équipe. La règle d'approbation par défaut de Claude les couvre tous, et Claude n'a que les droits de la personne qui a branché PagerDuty.
03Claude me demande-t-il avant d'appeler quelqu'un dans PagerDuty ?
Par défaut, oui : Claude demande une confirmation avant chaque action qu'il mène sur un compte à ta place. Aucune source ne décrit de confirmation propre à un outil PagerDuty, donc c'est cette règle qui couvre nouveaux incidents, intervenants ajoutés et workflows lancés. Sur Team et Enterprise, les propriétaires décident si les membres peuvent sauter certaines confirmations et peuvent limiter le connecteur à la lecture. Côté PagerDuty, un client OAuth à périmètre restreint limite les outils qui aboutissent.
04Sur quels plans est-ce disponible ?
Aucune source officielle ne publie la disponibilité par plan connecteur par connecteur, et aucune des 819 fiches du répertoire ne l'affiche. La règle générale veut que les connecteurs distants soient ouverts à tous les utilisateurs sur Claude, Cowork, Claude Desktop et mobile. Sur Team et Enterprise, un Owner ou un Primary Owner active le connecteur pour l'organisation avant que les membres s'y connectent un par un. La fiche du répertoire reste le seul endroit qui montre l'état à jour pour ton compte.
05Claude voit-il tout notre compte PagerDuty ?
Claude atteint ce que l'accès PagerDuty que tu as autorisé atteint, et rien de plus. PagerDuty ajoute que certains outils et filtres demandent un accès au niveau utilisateur, donc une connexion au niveau du compte ne répond pas forcément de la même façon à toutes les questions. Un client OAuth restreint côté PagerDuty peut réduire les outils qui aboutissent. Côté Claude, un propriétaire d'espace Team ou Enterprise peut restreindre le connecteur pour tous, et un membre ne peut pas lever cette limite.
06Pourquoi les outils PagerDuty de Claude ne collent pas à la doc de PagerDuty ?
Parce que deux listes officielles coexistent. La fiche du répertoire affiche 64 noms d'outils détaillés qui correspondent au serveur auto-hébergé de PagerDuty, que l'éditeur a archivé. La base de connaissances actuelle de PagerDuty décrit son serveur hébergé avec des outils regroupés, un pour consulter et un pour gérer chaque domaine. Cette page suit les noms du répertoire et prend leur classement dans le tableau archivé de PagerDuty. Vérifie la liste que montre ton compte connecté pour savoir ce que tu as vraiment.
07Claude ou un outil d'automatisation pour PagerDuty ?
Ils ne font pas le même métier, donc tout dépend de l'usage. Claude travaille pendant une conversation : tu poses une question sur un incident, il appelle un outil, tu valides et tu vérifies. Un outil d'automatisation tourne en arrière-plan quand un événement survient, comme un nouvel incident qui doit ouvrir un ticket ailleurs. Le connecteur n'a aucun outil qui démarre seul. Pour relier ses événements à d'autres applications, une plateforme d'automatisation est le bon choix.