Aller au contenu principal

La page d'état

Votre déploiement kuploy-cloud est livré avec une page d'état publique sur /status — par exemple https://console.example.com/status. Elle affiche la santé de vos composants en temps réel et vous permet de publier des incidents à l'attention de vos clients.

Elle fonctionne de concert avec la page d'état centrale de la plateforme, sur kuploy.app/status — ou là où pointe votre LICENSE_HUB_URL —, qui couvre la plateforme en amont dont vous dépendez : le centre de licences, la facturation, le registre central.

Ce que voient vos clients​

La page est publique, sans connexion. Trois sections, de haut en bas :

SectionContenu
Le bandeau d'état« All systems operational », « Degraded » ou « Major outage »
Les incidents en coursTout incident que vous avez publié et qui n'est pas encore résolu
Les composantsUne ligne par composant, avec ses 90 derniers jours de disponibilité
Les incidents passésLes incidents résolus des 14 derniers jours

La page se rafraîchit toutes les 30 secondes. Vos clients n'ont pas besoin de compte pour la consulter.

Les composants suivis​

D'emblée :

ComposantSonde
DashboardUn GET /api/health HTTP sur ce déploiement
DatabaseUn SELECT 1 sur le Postgres principal
Email HostingUn appel à l'API de gestion de Stalwart (seulement si configurée)
Container RegistryUn appel au /v2/ du registre (seulement s'il est configuré)
Build RunnerUne sonde de santé de la file — qui signale lorsque plus de 50 déploiements sont running depuis plus d'une heure
Custom Domain DNSRésout l'un des domaines personnalisés enregistrés (seulement s'il y en a)

Email Hosting, Container Registry et Custom Domain DNS sont masqués tant qu'ils ne sont pas configurés : ils n'apparaissent sur la page publique que lorsqu'il y a quelque chose à sonder. Dashboard, Database et Build Runner s'affichent toujours.

Comment tournent les sondes​

kuploy-cloud exécute ses sondes dans son propre processus, sur un ordonnanceur interne — le même mécanisme que la synchronisation de licence et le détecteur de builds coincés. Il n'y a ni cron à configurer, ni Vercel, ni CronJob Kubernetes. Dès que le pod du locataire est en service, les sondes partent toutes les cinq minutes, automatiquement.

La cadence est pilotée par la variable d'environnement STATUS_PROBE_INTERVAL_SECONDS (bornée entre 60 et 3600 ; 300, soit 5 minutes, par défaut). Changez-la et redéployez.

Le point d'accès manuel de la sonde

Il existe toujours une route HTTP /api/cron/status-probe, protégée par CRON_SECRET — conservée pour les usages manuels d'exploitation. Vous n'avez pas besoin de la planifier : c'est la boucle interne au processus qui fait foi.

Publier des incidents​

Lorsque quelque chose va de travers et que vous voulez en informer vos clients sans attendre :

  1. Connectez-vous en tant qu'administrateur de plateforme
  2. Admin → Status — Incidents
  3. New incident : un titre, une gravité, éventuellement un composant, et la description destinée au public
  4. À mesure que la situation évolue, publiez des mises à jour depuis cette même ligne, pour avancer de Investigating à Identified, puis Monitoring, puis Resolved
  5. Une mise à jour publiée avec l'état Resolved fait passer l'incident dans « Past incidents (14 days) »

Les incidents que vous publiez apparaissent immédiatement sur la page publique /status ; aucun déploiement n'est nécessaire.

L'état des composants reste automatique

Vous ne basculez pas « operational » ou « down » à la main : cela vient des sondes. Les incidents ajoutent par-dessus le récit humain — ce qui s'est passé, ce que vous faites, et quand c'est réglé.

Les gravités​

GravitéÀ utiliser pour
MinorUn seul composant non critique dégradé, avec des contournements
MajorUne perturbation visible de vos clients, qui gêne l'usage normal
CriticalUne indisponibilité importante, ou un risque sur les données
MaintenanceLes fenêtres de maintenance planifiées, annoncées à l'avance

La ligne de la plateforme en amont​

Votre page d'état affiche une ligne Upstream platform, en haut, dès lors que le /api/status du centre de licences est joignable. L'URL est résolue dans cet ordre :

  1. PLATFORM_STATUS_URL — le réglage explicite, qui prime
  2. LICENSE_HUB_URL + /api/status — le centre auprès duquel vous avez votre licence
  3. https://kuploy.app/api/status — la valeur par défaut

Vos clients peuvent ainsi constater que « l'amont va bien, le problème est local » — ou l'inverse — sans quitter votre page d'état.

Pour masquer la ligne entièrement — sur un déploiement coupé du réseau, par exemple —, définissez PLATFORM_STATUS_URL="", à vide.

Un déroulé pragmatique, qui fonctionne bien avec ce système :

  1. Découvrez un problème : une alerte, un signalement client, un journal.
  2. Reconnaissez-le publiquement en quelques minutes, en publiant un incident Minor ou Major à l'état Investigating. Vos clients cessent de se poser des questions.
  3. Mettez à jour au moins toutes les demi-heures tant que l'incident est en cours, même si la seule chose à dire est « toujours en cours d'investigation, rien de nouveau » : le silence est pire que l'absence de nouvelles.
  4. Résolvez avec une ligne de synthèse sur la cause racine, pour que vos clients puissent la relire plus tard dans la liste des incidents des 14 derniers jours.

Prévenir votre équipe des incidents​

Les incidents que vous publiez peuvent aussi être diffusés vers vos canaux de notification configurés — Slack, Discord, courriel, Telegram, etc. —, par la même chaîne qui traite les événements de consommation et de tickets d'assistance.

Trois événements sont disponibles :

  • Status: Incident Created — déclenché à la publication d'un nouvel incident ;
  • Status: Incident Updated — déclenché à chaque mise à jour (investigating, identified, monitoring) ;
  • Status: Incident Resolved — déclenché à la résolution d'un incident.

Tous trois sont désactivés par défaut, contrairement aux événements de tickets d'assistance, afin que vos canaux existants ne reçoivent pas soudainement une nouvelle catégorie de notifications. Activez-les canal par canal, depuis Account → Billing → Notification Channels.

Voir Notifications de facturation pour la configuration des canaux.

Les alertes d'état de la plateforme en amont​

Votre déploiement surveille automatiquement l'état global du centre de licences en amont, par LICENSE_HUB_URL. Lorsque l'état du centre change — d'opérationnel à panne majeure, ou de panne à opérationnel —, une notification Platform Status Changed partira par vos canaux configurés.

Cet événement est actif par défaut sur tous les canaux, pour que les exploitants soient alertés sans délai quand l'amont dont ils dépendent tombe ou se rétablit. Désactivez-le canal par canal si vous préférez consulter la page /status à la main.

Une API JSON, pour la supervision par un tiers​

Votre déploiement expose également un point d'accès JSON public sur /api/status, sans authentification. Il renvoie les mêmes données que celles affichées par la page /status — l'état global, la santé de chaque composant, les incidents en cours et récents — dans un format exploitable par une machine.

Utilisez-le avec des services comme UptimeRobot, BetterStack, Pingdom, ou tout outil qui interroge une URL et alerte sur une valeur autre que "operational". Par exemple :

curl -s https://votre-locataire.example.com/api/status | jq .overall
# "operational"

Le lien n'est volontairement pas affiché sur la page publique /status, afin de garder la surface visible de vos clients épurée. Il est documenté ici pour les exploitants qui en ont besoin.

Personnaliser la page​

La page d'état reprend automatiquement l'habillage de votre locataire, depuis Admin → Theme & Branding :

Champ du thèmeOù il apparaît sur /status
Site nameLe titre de l'en-tête et l'onglet du navigateur (<Locataire> — Status)
LogoL'en-tête, à côté du nom du site
FaviconL'icône de l'onglet du navigateur
Theme colors (HSL)L'habillage de la page : fond, bordures, liens, accents
Footer copyrightLa ligne de pied de page, au-dessus de « Status snapshot refreshes… »
Custom CSSInjectée globalement ; peut tout surcharger sur la page

Les couleurs d'état des composants — vert, jaune, orange et rouge pour operational, degraded, partial et major — ne sont volontairement pas habillées : ce sont des conventions universelles, et les personnaliser désorienterait vos lecteurs.

Un domaine personnalisé​

La page d'état est servie sur /status, quel que soit le nom d'hôte auquel répond votre instance kuploy-cloud. Si vous avez configuré un domaine personnalisé pour votre déploiement — cloud.example.com, par exemple —, la page est automatiquement joignable sur https://cloud.example.com/status, sans rien de plus à faire : cette route n'a rien de particulier.

Vous préférez un nom d'hôte dédié, status.example.com ? Faites pointer un enregistrement A ou CNAME vers votre déploiement, et la route /status répondra aussi sur cet hôte. Aucune modification de code n'est nécessaire.