Contrôles uptime & pages de statut

En complément de l’agent (inside-out), le hub peut aussi vérifier outside-in que vos services sont joignables : des contrôles HTTP(S) et TCP exécutés depuis le hub, sans agent sur le serveur cible. Les résultats alimentent une page de statut publique pour vos clients ou collègues.

Créer des contrôles

1. Barre latérale → Uptime
2. Cliquez + Check et renseignez :
   • Nom : texte libre, apparaît aussi sur la page de statut
   • Type : http (suit les redirections, valide TLS) ou tcp (port ouvert ?)
   • Cible : URL complète (https://…) ou hôte:port pour tcp
   • Intervalle : 30 à 3600 secondes
   • Timeout : 1 à 60 secondes, toujours inférieur à l’intervalle
   • Statut attendu (http) : par exemple 200

Limites : maximum 50 contrôles par tenant. Les cibles pointant vers des plages IP internes ou privées (loopback, RFC1918, link-local) sont refusées : le hub ne se laisse pas utiliser comme proxy SSRF.

Comment le hub décide qu’un service est down

• Le worker planifie chaque contrôle selon son propre intervalle (tick du scheduler : 15 s).
• Un contrôle ne passe à down qu’après 2 échecs consécutifs. Un simple hoquet réseau ne déclenche donc pas d’alerte (protection anti-flapping).
• En cas de down, une alerte critique (uptime.down) entre dans le pipeline d’alertes habituel : mêmes canaux de notification, même flux d’acquittement.
• Quand le contrôle se rétablit, l’alerte est résolue automatiquement.

Détection d’expiration TLS

À chaque contrôle https, le hub lit la chaîne de certificats. Si le certificat expire dans les 14 jours, une alerte warning (uptime.cert_expiring) apparaît avec la date d’expiration. Après renouvellement, l’alerte disparaît d’elle-même au contrôle suivant.

Pages de statut publiques

1. Barre latérale → Uptime → section Pages de statut
2. Choisissez un titre, un slug et les contrôles à afficher.
3. La page est immédiatement accessible publiquement sur :

https://app.monsys.ai/<locale>/s/<slug>

Lisible par machine (JSON, pour vos propres intégrations) :

https://api.monsys.ai/v/status/<slug>

Ce que voient les visiteurs : le nom de chaque contrôle, le statut actuel et le pourcentage d’uptime sur 30 jours. Ce qu’ils ne voient jamais : la cible elle-même (URL, nom d’hôte, port). Les pages de statut ne divulguent donc aucune infrastructure.

Visibilité d’une page de statut

Pour chaque page, vous choisissez comment elle est accessible :

Mode	Comportement
public (par défaut)	toute personne connaissant le slug voit la page
token	uniquement via un lien secret …/s/<slug>?token=<token> ; le token peut être renouvelé via Renouveler le token — l’ancien lien cesse de fonctionner immédiatement
password	le visiteur saisit un mot de passe (8–128 caractères) ; le hub ne conserve qu’un hash bcrypt et vérifie côté serveur

Passer de public à token ou password fait renvoyer 404/401 à l’URL publique (et au point de terminaison JSON) pour quiconque n’a pas la clé.

Rôles

Rôle	Peut
Viewer	consulter contrôles et résultats
Editor	créer, modifier, supprimer contrôles et pages de statut
Admin	idem

Par rapport à la surveillance par agent

Aspect	Agent (inside-out)	Contrôle uptime (outside-in)
Agent requis sur l’hôte	oui	non
Voit	CPU, disque, services, logs, CVE	la joignabilité et le TLS tels qu’un visiteur les voit
Détecte	la cause	le symptôme

Utilisez les deux : le contrôle uptime vous dit qu’un service est tombé, l’agent vous dit pourquoi.