uptimelens/claude-plugins

Surveillance UptimeLens

Configurez et exécutez la surveillance de disponibilité UptimeLens sur les ressources propres du client, via le serveur MCP UptimeLens. Cette skill transforme une demande de surveillance (« surveille cette URL », « que dois-je surveiller après ce déploiement ? », « qu'est-ce qui est en panne ? », « ouvre un incident ») en la séquence correcte d'appels d'outils MCP.

Quand utiliser cette skill

Utilisez-la pour la configuration de la surveillance et la tenue de registre des incidents :

• Création de moniteurs HTTP/HTTPS, et recommandation de couverture après un déploiement ou pour un nouveau service.
• Vérification de ce qui est actuellement en panne et investigation légère (historique des statuts, cause racine par sonde, temps de réponse/disponibilité).
• Planification d'une fenêtre de maintenance pour qu'un déploiement ou des travaux planifiés ne déclenchent pas d'alerte.
• Modélisation des dépendances entre moniteurs afin qu'un contrôle aval n'alerte pas lorsque son amont est déjà en panne.
• Ouverture, mise à jour ou résolution d'incidents.

Passez la main lorsque la demande concerne la réponse à un incident plutôt que la surveillance : pour accuser réception ou mettre en sourdine une escalade active, assurer une garde, ou inspecter les exécutions d'escalade, utilisez la skill uptimelens-on-call. Pour une investigation approfondie et guidée de la cause racine d'un incident, préférez le prompt MCP triage_incident en lecture seule (et l'outil get_root_cause) plutôt que de coder toute l'analyse ici.

Prérequis

1. Le serveur MCP UptimeLens est connecté à ce client. Les outils de lecture fonctionnent sur tous les plans.
2. Les actions en écriture (create_monitor, update_monitor, pause_monitor, resume_monitor, register_monitor_dependency, delete_monitor_dependency, create_incident, post_incident_update, resolve_incident, cancel_incident, reopen_incident, save_postmortem, add_incident_action_item, create_maintenance, delete_maintenance) nécessitent un jeton API en lecture-écriture et un plan Pro ou supérieur. Avec un jeton en lecture seule, les outils d'écriture ne sont même pas listés ; sur le plan Gratuit, ils retournent FeatureNotAvailable.
3. Certains outils de lecture sont limités par plan. get_root_cause (payant) et get_incident_analytics (Pro+) sont limités en dur — sous le plan requis, ils retournent une erreur FeatureNotAvailable ; gérez-la comme les prérequis des outils d'écriture ci-dessous (dites à l'utilisateur que le plan n'est pas atteint, ne réessayez pas). Les centiles de query_metrics sont limités en souple — les champs de centiles sont null sous le plan Team, pas d'erreur.

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 en utilisant leur nom complet UptimeLens:<outil> — remplacez UptimeLens par le nom donné au connecteur dans ce client, sinon l'outil pourrait ne pas être trouvé.

Lecture (découverte et contexte) :

• UptimeLens:get_overview — commencez ici pour « qu'est-ce qui est cassé maintenant ? » : nombre de moniteurs par statut, disponibilité sur 24 heures, incidents ouverts, et les échecs distincts regroupés — quarante moniteurs qui ont échoué de la même manière sur la même cible apparaissent comme UNE seule panne au lieu de quarante lignes. Utilisez list_monitors à la place lorsque vous avez besoin de l'inventaire lui-même (noms, tags, ids).
• UptimeLens:list_monitors — moniteurs avec leur état de santé actuel ; filtrez par status (up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance), nom ou tags. La source du monitorId pour presque tout le reste, et la réponse à « qu'est-ce qui est en panne ? ».
• UptimeLens:get_monitor — configuration et état de santé actuel d'un moniteur (pas d'identifiants).
• UptimeLens:list_status_changes — historique des changements de statut up/down/degraded d'un moniteur avec durées ; la source du statusChangeId dont get_root_cause a besoin.
• UptimeLens:get_status_change — un changement de statut avec son contexte (changement précédent et suivant, l'incident et les exécutions d'escalade qui le couvrent) et un résumé par localisation des vérifications autour de celui-ci : combien ont échoué, firstDownAt, et la errorCategory la plus fréquente. Utilisez-le pour dire où une panne a commencé et comment elle a été confirmée ; disponible sur tous les plans.
• UptimeLens:get_root_cause — diagnostics réseau par sonde pour un changement de statut : timing DNS/connect/TLS, traceroute, version TLS, jours restants SSL, catégorie d'erreur. La source la plus riche pour « pourquoi était-ce en panne » (plan payant).
• UptimeLens:query_metrics — statistiques de temps de réponse et de disponibilité pour un moniteur sur une période (résumé de période, pas une série complète ; les centiles sont Team+).
• UptimeLens:get_monitor_availability — vue SLA pour un moniteur : % de disponibilité, temps d'arrêt, nombre d'incidents, MTTR, MTBF, stats de temps de réponse. Lecture : un uptimePct absent signifie que la période n'a eu AUCUNE mesure — ce n'est PAS 100, dites donc que le moniteur n'a pas été mesuré ; longestIncidentSec est le temps d'horloge d'un incident et PEUT dépasser le totalDowntimeSec mesuré — c'est attendu, pas une erreur de données ; uptimePct est arrondi à deux décimales, donc une panne très courte peut afficher 100.00 à côté d'un temps d'arrêt positif ; un mtbfSec/mttrSec absent n'est PAS zéro.
• UptimeLens:get_uptime_report — la même question pour le compte entier sur une période : disponibilité pondérée dans le temps, temps d'arrêt, budget d'erreur par rapport à un objectif SLA, plus ce qui a cassé (causes) et d'où cela a été confirmé (locations). Choisissez une période avec un préréglage (last_month, last_30d, …) ou des dates explicites. Utilisez ceci pour « comment s'est passé le mois dernier ? » ; get_monitor_availability pour un seul moniteur.
• UptimeLens:list_monitor_dependencies — les moniteurs parents dont dépend un moniteur (ce qui doit être opérationnel pour que ses alertes se déclenchent).
• UptimeLens:list_monitor_dependents — l'inverse : les moniteurs qui dépendent de celui-ci — son rayon d'explosion, pour distinguer la cause racine du symptôme.
• UptimeLens:list_incidents — incidents, du plus récent au plus ancien ; par défaut les 7 derniers jours sauf si vous passez startDate/endDate. Filtrez par status, monitorId ou source.
• UptimeLens:get_incident — détails d'un incident plus sa chronologie de mises à jour et les moniteurs affectés.
• UptimeLens:get_incident_analytics — métriques d'incidents au niveau de la flotte sur une plage de dates (MTTR, volume/tendance, répartition gravité/source, principaux moniteurs) — Pro+.
• UptimeLens:list_maintenance — fenêtres de maintenance ; status=active répond à « y a-t-il quelque chose en maintenance maintenant ? ».
• UptimeLens:list_status_pages / UptimeLens:get_status_page — ce qui est publié pour les clients et quels moniteurs apparaissent sur une page (utile pour décider de la couverture).

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

• UptimeLens:create_monitor — créer un moniteur HTTP/HTTPS à partir d'une URL. Voir « Ce que create_monitor peut et ne peut pas faire ».
• UptimeLens:update_monitor — modifier le nom et/ou l'intervalle de vérification d'un moniteur existant (id + name et/ou intervalSeconds, au moins un). Tous les autres paramètres (URL, type, authentification, en-têtes, seuils, régions) sont conservés intacts et ne peuvent pas être modifiés via MCP. Réversible et idempotent.
• UptimeLens:pause_monitor / UptimeLens:resume_monitor — arrêter ou redémarrer la surveillance active d'un moniteur. Entrée : id. Réversible et idempotent.
• UptimeLens:register_monitor_dependency — déclarer une dépendance enfant→parent : lorsque le parent est en panne, les alertes de panne de l'enfant sont supprimées. Entrée : monitorId (enfant), parentId. Parent direct uniquement ; cycles/auto-référence rejetés.
• UptimeLens:delete_monitor_dependency — supprimer une arête de dépendance par son id d'enregistrement (de list_monitor_dependencies) ; ne supprime aucun moniteur.
• UptimeLens:create_incident — ouvrir un incident. Voir « Les incidents s'ouvrent comme brouillons ».
• UptimeLens:post_incident_update — ajouter une mise à jour de la chronologie (investigating/identified/monitoring) avec un message. Les abonnés ne sont pas prévenus par email sauf si vous passez notifySubscribers=true (et seulement si l'incident est déjà publié).
• UptimeLens:resolve_incident — marquer un incident comme résolu. Les abonnés ne sont pas prévenus par email sauf si vous passez notifySubscribers=true (et seulement si publié). Réversible via reopen_incident.
• UptimeLens:cancel_incident — annuler comme false_alarm/duplicate/test ; terminal (ne peut pas être rouvert), exclu des analyses. Silencieux par défaut.
• UptimeLens:reopen_incident — rouvrir un incident précédemment résolu (un incident annulé ne peut pas être rouvert).
• UptimeLens:save_postmortem — écrire (ou réécrire) le corps du post-mortem d'un incident en markdown ; status optionnel de draft ou in_review. C'est là que la sortie du prompt postmortem_draft est destinée — sans cela, le brouillon n'existe que dans le chat. La publication reste une étape humaine dans le tableau de bord.
• UptimeLens:add_incident_action_item — ajouter un élément d'action de suivi à un incident (titre, plus type, priorité et date d'échéance optionnels). La moitié d'un post-mortem qui change réellement quelque chose.
• UptimeLens:create_maintenance / UptimeLens:delete_maintenance — planifier ou annuler une fenêtre de maintenance qui supprime les alertes pour ses moniteurs pendant la fenêtre.

Flux de travail principal : configurer la surveillance (surtout après un déploiement)

La découverte vient en premier : presque chaque écriture a besoin d'un ID, ou d'une décision que seul l'inventaire actuel peut informer. Copiez cette liste de contrôle et parcourez-la :

Configurer la surveillance :
- [ ] 1. Voir la couverture actuelle (list_monitors) — ce qui existe, ce qui manque, ce qui est déjà en panne
- [ ] 2. Pour une nouvelle URL/service : vérifier list_monitors pour un doublon (create_monitor n'est PAS idempotent)
- [ ] 3. Confirmer la/les URL avec l'utilisateur, puis create_monitor (HTTP/HTTPS uniquement)
- [ ] 4. Câbler la topologie si pertinent (register_monitor_dependency : la nouvelle vérification sous son amont)
- [ ] 5. Si un déploiement/maintenance a lieu, réduire le bruit (create_maintenance pour la fenêtre)

Étape 1 — inventaire. Appelez list_monitors. Pour répondre à « qu'est-ce qui est en panne ? », passez `status=[