UptimeLens Astreinte

Que fait UptimeLens Astreinte ?

Opérez les workflows d'astreinte et d'escalade UptimeLens sur les propres ressources du client, via le serveur MCP UptimeLens. Cette compétence transforme une question d'alerte (« qui est d'astreinte ? », « accuse réception de cette page », « couvre mon quart ») en la séquence correcte d'appels d'outils MCP.

Quand utiliser cette compétence

Utilisez-la pour le côté opérationnel de l'alerte d'incident :

• Trouver qui est actuellement d'astreinte (ou pourquoi personne ne l'est).
• Accuser réception ou reporter une escalade active qui est en train de paguer quelqu'un.
• Couvrir un quart de travail en écrasant un roulement d'astreinte pour une fenêtre de temps.
• Inspecter les exécutions d'escalade (pages actives + historique) et les politiques d'escalade.

Pour l'analyse des causes profondes d'un incident (par opposition à la gestion de la page), préférez le prompt MCP en lecture seule triage_incident, ou les outils de lecture get_incident, get_root_cause, list_status_changes, et query_metrics. Cette compétence reste sur la couche d'astreinte/escalade et ne fait le lien avec le contexte d'incident que lorsque cela aide à décider qui doit agir.

Prérequis

1. Le serveur MCP UptimeLens est connecté à ce client. Les outils de lecture fonctionnent sur tous les plans.
2. Les actions d'écriture (acknowledge_escalation, bulk_acknowledge_escalation, resolve_escalation, snooze_escalation, escalate_escalation, create_on_call_override, update_on_call_override, delete_on_call_override, create_cover_request, accept_cover_request, decline_cover_request) nécessitent un token API en lecture-écriture et un plan Pro ou supérieur. Avec un token en lecture seule, les outils d'écriture ne sont même pas listés ; sur le plan Free, ils retournent FeatureNotAvailable.
3. Certaines de ces actions comportent une seconde porte, par fonctionnalité, en plus de la porte du plan, et elles ne sont pas toutes les mêmes :
   • create_on_call_override, update_on_call_override et accept_cover_request nécessitent la fonctionnalité d'écrasement de roulement d'astreinte. Accepter compte car cela produit un écrasement actif — exactement ce que vend la fonctionnalité. (Une demande en attente créée sur un plan payant et acceptée après une rétrogradation créerait autrement un écrasement que le plan n'inclut plus ; cette lacune a été délibérément comblée.)
   • create_cover_request nécessite une fonctionnalité différente — les demandes de couverture d'astreinte — de sorte qu'un plan peut inclure l'une et pas l'autre.
   • delete_on_call_override et decline_cover_request sont délibérément non restreintes : annuler quelque chose doit rester possible après une rétrogradation, sinon un échange de quart que vous ne pouvez plus modifier est aussi un que vous ne pouvez plus annuler. Chacune d'elles peut retourner FeatureNotAvailable même avec un token en lecture-écriture.

Si un outil d'écriture est manquant ou retourne FeatureNotAvailable, dites à l'utilisateur quel prérequis n'est pas satisfait au lieu de réessayer.

Outils

Ces outils proviennent du serveur MCP UptimeLens. Référencez-les avec leur nom complet comme UptimeLens:<outil> — remplacez UptimeLens par le nom que le connecteur a reçu dans ce client, sinon l'outil pourrait ne pas être trouvé.

Lecture (découverte et contexte) :

• UptimeLens:list_on_call_schedules — plannings ; source du scheduleId dont who_is_on_call et create_on_call_override ont besoin.
• UptimeLens:who_is_on_call — qui est d'astreinte pour un planning en ce moment ; retourne gapReason quand personne ne l'est.
• UptimeLens:get_on_call_schedule — le prochain effectif pour un planning sur les N prochains jours (7 par défaut, max 90) : chaque quart (qui, quand, roulement vs écrasement), les lacunes de couverture avec leur raison, et un résumé de couverture. Utilisez-le pour la couverture future ; who_is_on_call est seulement pour maintenant.
• UptimeLens:list_on_call_overrides — les écrasements actifs et à venir pour un planning ; la source de l'id dont update_on_call_override et delete_on_call_override ont besoin. Chaque entrée porte l'utilisateur (qui prend le quart), le demandeur (requestedBy, défini uniquement pour une demande de couverture en attente — qui a demandé la couverture), la fenêtre, la raison et l'état. Seul un écrasement active est modifiable ; une entrée pending est une demande de couverture attendant encore l'acceptation de l'utilisateur cible, et update_on_call_override la rejettera. Les écrasements passés ne sont pas listés.
• UptimeLens:list_escalation_runs — exécutions d'escalade (pages actives + historique) ; source du runId dont acknowledge_escalation, snooze_escalation et escalate_escalation ont besoin. La progression est basée sur 1 : currentStep (l'étape que l'escalade a atteinte), nextStep (se déclenche ensuite), totalSteps.
• UptimeLens:get_escalation_run — l'état complet d'une exécution : quelle étape l'escalade a atteinte et laquelle se déclenche ensuite (currentStep/nextStep de totalSteps), la progression des répétitions, l'urgence, la méthode d'accusé de réception/résolution (POURQUOI cela s'est terminé), les délais de report et d'expiration d'accusé de réception, nextActionAt, l'incident/moniteur déclencheur.
• UptimeLens:get_escalation_run_timeline — le journal chronologique des événements d'une exécution : notifications, résultats de livraison, expirations d'accusé de réception, cibles ignorées, répétitions, résolution — la source la plus riche pour « ce qui s'est passé / pourquoi cela a escaladé ».
• UptimeLens:list_escalation_policies — les règles d'alerte d'astreinte.
• UptimeLens:get_escalation_policy — le détail d'une politique : étapes ordonnées numérotées 1..N (les numéros currentStep/nextStep dans list_escalation_runs y font référence), le délai de chaque étape, la stratégie et les cibles. Résolvez les cibles de planning via who_is_on_call, les cibles utilisateur via list_team_members.
• UptimeLens:list_team_members — les personnes de l'équipe ; source du userId dont create_on_call_override a besoin.

Écriture (changement d'état — voir « Confirmer avant d'écrire ») :

• UptimeLens:acknowledge_escalation — arrêter la pagination pour une exécution active. Entrée : runId.
• UptimeLens:resolve_escalation — fermer la page définitivement. Entrée : runId. Contrairement à l'accusé de réception, une exécution résolue ne repage jamais, alors utilisez-la quand le problème sous-jacent est confirmé comme résolu — pas comme un moyen de faire cesser une alerte bruyante.
• UptimeLens:bulk_acknowledge_escalation — accuser réception de plusieurs exécutions actives à la fois. Entrée : runIds (1–50). Succès partiel : les exécutions déjà résolues/inconnues sont comptées comme ignorées, pas comme des erreurs. Utilisez après list_escalation_runs(state=active) pour traiter un lot.
• UptimeLens:snooze_escalation — mettre en pause la pagination pour une exécution pendant un nombre de minutes. Entrée : runId, durationMinutes (1–240).
• UptimeLens:escalate_escalation — paguer la prochaine étape pas encore pagée maintenant au lieu d'attendre son minuteur (« escalader maintenant »). Entrée : runId. Rien n'est ignoré : l'étape montrée comme nextStep se déclenche ; après la dernière étape, la répétition suivante commence immédiatement, et sans répétition restante, l'exécution est fermée comme épuisée (nextStep est 0 — dites à l'utilisateur qu'il n'y a plus personne à paguer). L'exécution repasse à active et son urgence devient high. Rejeté pour les exécutions de test et les exécutions terminées.
• UptimeLens:create_on_call_override — mettre un utilisateur d'astreinte pour un planning pendant une fenêtre. Entrée : scheduleId, userId, endAt ; startAt optionnel (par défaut maintenant), reason optionnel. Nécessite la fonctionnalité d'écrasement de roulement d'astreinte (voir prérequis).
• UptimeLens:update_on_call_override — modifier un écrasement existant sur place : changer son endAt ou reason, et (uniquement avant qu'il ne commence) son userId ou startAt. Entrée : id (du résultat de create_on_call_override, ou découvert via list_on_call_overrides quand vous ne venez pas de le créer) plus les champs à modifier ; omettez un champ pour le laisser inchangé. C'est ainsi que vous raccourcissez, prolongez ou réaffectez une couverture ; utilisez delete_on_call_override quand l'échange ne doit pas du tout avoir lieu. Nécessite la fonctionnalité d'écrasement de roulement d'astreinte.
• UptimeLens:delete_on_call_override — supprimer un écrasement purement et simplement : l'échange est annulé et le roulement régulier s'applique à nouveau. Entrée : id. Utilisez ceci plutôt que de modifier quand la couverture ne doit pas du tout avoir lieu.
• UptimeLens:create_cover_request — demander à un coéquipier de prendre une fenêtre au lieu de l'assigner : crée une demande pending et envoie un e-mail à la cible, qui doit accepter avant qu'elle ne devienne un écrasement actif. Entrée : scheduleId, userId (qui est sollicité), startAt, endAt ; reason optionnel. Utilisez create_on_call_override quand vous avez l'intention d'assigner le quart immédiatement sans demander.
• UptimeLens:accept_cover_request — accepter une demande de couverture pending → elle devient un écrasement actif (l'utilisateur cible prend le quart). Entrée : id (une entrée pending de list_on_call_overrides). Seul l'utilisateur cible ou un administrateur peut accepter.
• UptimeLens:decline_cover_request — refuser une demande de couverture pending (aucun écrasement n'est créé). Entrée : id (une entrée pending de list_on_call_overrides). Seul l'utilisateur cible ou un administrateur peut refuser.

Flux de travail principal : gérer une alerte d'astreinte

La plupart des outils d'écriture ont besoin d'un ID que seul un outil de lecture peut fournir, alors découvrez toujours d'abord. Copiez cette liste de contrôle et parcourez-la :

Réponse d'astreinte :
- [ ] 1. Trouver les exécutions d'escalade actives (list_escalation_runs, state=active, isTest=false)
- [ ] 2. Choisir l'exécution en question (classer par startedAt ; vérifier l'urgence et currentStep/totalSteps)
- [ ] 3. Ajouter du contexte si utile (incidentId → get_incident ; triggeringMonitorId → list_status_changes → get_root_cause)
- [ ] 4. Décider : accuser réception (prendre en charge, la pagination cesse) ou reporter (pause N minutes, la pagination reprend)
- [ ] 5. Confirmer l'action avec l'utilisateur, puis appeler l'outil d'écriture avec l'id de l'exécution

Étape 1 — trouver les exécutions actives. Appelez list_escalation_runs avec state="active". Utilisez isTest=false pour les pages réelles déclenchées par un incident ; isTest=true sont des exécutions de test « pagez-vous » et ne doivent pas être traitées comme des incidents en direct.

Étape 2 — choisir l'exécution. Chaque exécution a un id (c'est le runId pour les outils d'écriture), urgency (high/low), currentStep de totalSteps (jusqu'où l'escalade a grimpé — basé sur 1 ; plus élevé signifie que plus de personnes ont été paguées ; nextStep est qui sera pagué ensuite), et startedAt. Lorsque plusieurs sont actives, classez par startedAt (la plus ancienne d'abord) et mettez en avant l'urgence high en premier.

Étape 3 — contexte (optionnel). Si l'exécution a un incidentId, appelez get_incident pour l'impact et la chronologie. Si elle a un triggeringMonitorId, appelez list_status_changes avec cet id de moniteur pour voir ses changements récents up/down, puis get_root_cause avec un statusChangeId de cette liste pour des diagnostics réseau par sonde. Utilisez ceci uniquement pour aider l'utilisateur à décider ; ne commencez pas une enquête complète ici.

Étape 4 / 5 — agir. Choisissez accuser réception vs reporter vs escalader (ci-dessous), confirmez, puis écrivez.

Accuser réception, résoudre, reporter ou escalader

• Accuser réception (acknowledge_escalation) signifie « je prends en charge maintenant » — la pagination s'arrête pendant que vous travaillez. C'est la bonne réponse pour « prendre », « j'ai compris », ou « faire taire » une page. Accuser réception d'une exécution qui n'est plus active retourne une erreur EscalationRunAlreadyResolved — inoffensive (elle était déjà accusée réception ou résolue) ; signalez-la comme déjà traitée et ne pas réessayer.

• Résoudre (resolve_escalation) signifie « c'est fini » — l'exécution est fermée définitivement et ne repage jamais. Utilisez-la quand l'utilisateur dit que le problème sous-jacent est résolu, pas simplement qu'il s'en occupe. Une exécution se résout aussi d'elle-même lorsque son incident se résout, donc résoudre manuellement est pour le cas où la page a survécu au problème. Comme elle ne peut pas être annulée, préférez accuser réception en cas de doute.

• Reporter (snooze_escalation) signifie « faites-la taire pendant durationMinutes, puis pagez à nouveau » — un report, pas une prise en charge. Ce n'est pas idempotent : chaque appel réinitialise la fenêtre de report à maintenant + N minutes, donc l'appeler à nouveau prolonge le silence. Utilisez la durée la plus petite qui convient (1–240), et ne reportez jamais au lieu d'accuser réception quand l'alerte a vraiment besoin d'un responsable.

• Escalader maintenant (escalate_escalation) signifie « il faut plus de monde, maintenant » — le nextStep de l'exécution est pagué immédiatement au lieu d'attendre son délai, l'urgence devient high (les heures de silence ne s'appliquent plus), et une exécution accusée réception redevient active. Utilisez-la quand l'utilisateur dit que le répondant actuel ne peut pas gérer ou que personne ne répond ; c'est l'inverse de reporter, donc n'appelez jamais les deux sur la même exécution en un seul tour. Dites à l'utilisateur quelle étape sera paguée (nextStep de get_escalation_run).

Accuser réception de la mauvaise exécution fait taire une vraie page et personne n'est alerté, alors confirmez que le runId correspond à l'alerte que l'utilisateur veut.

Lacunes de couverture

who_is_on_call retourne un gapReason quand personne n'est d'astreinte :

• schedule_disabled — le planning est désactivé ; la politique s'appuie sur d'autres cibles.
• no_active_rotations / no_rotation_members — le planning n'a personne d'assigné à paguer pour le moment.
• outside_active_window — en dehors des heures d'activité de ce planning.

Quand il y a une lacune et que quelqu'un doit prendre la page, create_on_call_override met un utilisateur spécifique d'astreinte pour une fenêtre. Découvrez scheduleId via list_on_call_schedules et userId via list_team_members (les membres de l'équipe n'exposent ni e-mail ni téléphone — faites correspondre par nom/rôle).

who_is_on_call ne signale que la lacune qui se produit maintenant. Pour trouver les lacunes avant qu'elles ne paguent quelqu'un, appelez get_on_call_schedule pour le planning — son tableau gaps liste chaque fenêtre non couverte sur les N prochains jours avec les mêmes raisons, et coveragePercent résume comment la période est couverte. C'est le complément proactif de who_is_on_call.

Confirmer avant d'écrire

Lisez et triez librement. Pour les outils d'écriture, indiquez ce que vous allez faire et obtenez d'abord l'accord de l'utilisateur — ces actions changent qui est pagué :

• Accuser réception / reporter : nommez l'exécution (urgence, ce qui l'a déclenchée) et, pour reporter, les minutes.
• Résoudre : dites clairement que la page est fermée pour de bon et ne repagera pas. Demandez si le problème sous-jacent est réellement résolu — « fais-la taire » est une demande d'accusé de réception ou de report, pas de résolution.
• Écrasement : nommez le planning, l'utilisateur et la fenêtre exacte (startAt–endAt, UTC RFC3339). Si la fenêtre chevauche minuit, la date de endAt est le jour suivant ; endAt doit être après startAt.
• Supprimer un écrasement / refuser une demande de couverture : nommez de qui le quart retourne au roulement régulier. Annuler une couverture change qui est pagué tout autant qu'en créer une.

La plupart de ces actions sont réversibles — un écrasement peut être modifié ou raccourci, un accusé de réception ou un report peut être ré-escaladé — l'objectif est donc une décision humaine claire, pas un mur de permissions. Deux ne le sont pas :

...