Uptime, SSL et page de statut publique

Le suivi d'exceptions vous dit que l'app échoue ; la surveillance uptime vous dit qu'elle ne répond plus du tout. Quiet Guard sonde une URL de votre choix, alerte sur la transition, garde un historique de latence, surveille le certificat TLS, et peut partager tout cela sur une page de statut publique.

La sonde active

Définissez une URL à vérifier dans les Réglages du projet (section Surveillance uptime). Toutes les cinq minutes, Quiet Guard envoie une requête GET :

• Tout statut inférieur à 400 compte comme opérationnel (redirections comprises), avec le temps de réponse enregistré comme latence.
• Un 4xx/5xx, un timeout (10 s) ou une erreur de connexion compte comme panne.
• L'URL doit être publique: les adresses privées et internes sont refusées par la même garde anti-SSRF que les webhooks.

Préférez un endpoint léger comme la route de santé /up de Laravel à une page d'accueil lourde : vous mesurez la disponibilité, pas le temps de rendu.

Alertes panne / rétablissement

Les alertes partent sur les transitions, pas à chaque vérification en échec : une alerte quand le site tombe, une quand il revient. Abonnez vos canaux aux événements uptime.down et uptime.recovered dans l'onglet Alertes du projet (voir Alertes). La protection anti-tempête s'applique.

Les sondes passant toutes les cinq minutes, une panne plus courte que l'intervalle entre deux vérifications peut passer inaperçue, la sonde est un détecteur de fumée, pas un analyseur de paquets.

Historique de latence

Chaque sonde enregistre un échantillon. La vue d'ensemble du projet affiche un graphe de temps de réponse sur 24 heures (fenêtres de 30 minutes, moyennes des vérifications réussies ; les fenêtres de panne apparaissent comme des trous, jamais comme de faux zéros). Les échantillons sont conservés sept jours, indépendamment de la rétention d'événements de votre forfait.

Expiration du certificat TLS

Pour les URL https, une tâche quotidienne lit le certificat directement sur la socket, cela fonctionne même quand la chaîne est cassée, et stocke la date d'expiration, affichée sur la vue d'ensemble du projet.

Vous êtes prévenu deux fois par certificat : une fois au passage sous 14 jours, une seconde à 3 jours (événement ssl.expiring, mêmes canaux). Un certificat renouvelé réarme le cycle. Un certificat déjà expiré n'a pas besoin d'alerte spéciale : la sonde des cinq minutes vérifie les pairs, donc le site tombe « en panne » et alerte par ce chemin.

Expiration de l'enregistrement du domaine

Un certificat peut se renouveler lui-même ; un domaine, non. Une tâche quotidienne demande au registre du domaine, via RDAP, la date d'expiration de son enregistrement, et l'affiche sur la vue d'ensemble du projet.

Vous êtes prévenu deux fois par domaine : une fois au passage sous 30 jours, une seconde à 7 jours (événement domain.expiring, mêmes canaux), des seuils plus larges que ceux du certificat, volontairement, puisqu'un renouvellement de domaine est un paiement et non une rotation automatisée. Un renouvellement réarme le cycle. Passé la date d'expiration, l'enregistrement est réellement échu, ce que consigne l'onglet Incidents du projet : un domaine échu entre dans une période de rédemption payante pour être récupéré auprès du bureau d'enregistrement.

Changements de zone DNS

Une seconde tâche quotidienne compare la zone, enregistrements A, AAAA, MX, NS et TXT, de l'hôte de l'URL surveillée à ce qui avait été observé la dernière fois. La première observation sert de référence, jamais d'alerte ; chaque changement suivant déclenche dns.changed (mêmes canaux), en nommant précisément les types d'enregistrement qui ont bougé et leurs valeurs avant/après. Les durées de vie (TTL) sont ignorées volontairement : elles décomptent entre deux lectures d'une zone inchangée et déclencheraient une alerte à chaque passage. Cela détecte un domaine détourné, une configuration mail cassée ou une modification accidentelle avant qu'un client ne s'en aperçoive.

Fichiers exposés

Sur activation, depuis l'onglet Vulnérabilités d'un projet, Quiet Guard demande chaque matin au site surveillé une liste fermée de chemins qui ne devraient jamais répondre publiquement. La base est l'origine de l'URL surveillée (schéma, hôte, port), jamais son chemin.

Un chemin n'est déclaré exposé que s'il répond 200 (ou 206) et que ses premiers octets ressemblent à ce qu'on cherche : une application monopage qui renvoie sa page d'accueil pour toute adresse inconnue n'est pas signalée. Une redirection, un 401, un 403, un 404 ou un 410 comptent comme protégés ; toute autre réponse (une limite de débit 429, un 408, un 5xx) ou une erreur réseau ne conclut rien, et l'état connu est gardé.

Rien de ce que le site répond n'est conservé. Quiet Guard lit au plus 8 Kio, décide en mémoire, et ne garde que le chemin, le code HTTP et la gravité. Les requêtes portent le user agent Quiet Guard-Exposure/1.0, pour que vous puissiez les reconnaître dans vos journaux ou les autoriser dans votre pare-feu applicatif.

Une nouvelle exposition déclenche l'événement exposure.detected (voir Alertes). Une exposition qui cesse de répondre passe en « Corrigé » sans alerte, et alerte de nouveau si elle revient. « Ignorer » fait taire un constat voulu tant qu'il répond.

Pour corriger : faire pointer la racine du serveur web sur le dossier public/ de l'application, bloquer les chemins restants, désactiver Ignition, Debugbar et Telescope en production, puis changer tout secret qui a pu être lu. Couper l'accès ne rend pas secret ce qui a déjà été lu.

N'activez cette recherche que pour un site que votre équipe exploite.

Incidents

La sonde uptime et la surveillance du domaine écrivent toutes deux dans un onglet Incidents partagé sur le projet : l'origine, le moment où l'incident a commencé, sa durée écoulée ou toujours en cours, et une note que votre équipe peut laisser ou modifier à tout moment, l'incident étant résolu ou encore ouvert. Pour un incident de disponibilité, cette note est la seule chose de cet onglet qui atteint la page de statut publique ci-dessous, à côté de la fenêtre de panne correspondante, pour un lecteur qui n'a jamais eu accès au panneau. La note d'un incident de domaine reste interne : un enregistrement échu n'est pas une panne du service que rapporte la page de statut.

La page de statut publique

Activez Page de statut publique dans les Réglages du projet et partagez le lien généré, un token non devinable constitue toute l'URL. La page montre :

• l'état actuel et, en cas de panne, depuis quand ;
• la disponibilité sur 7 jours: globale et en une barre par jour ;
• la latence actuelle et moyenne sur 24 heures ;
• la date de validité du certificat TLS ;
• les cinq dernières fenêtres de panne, chacune avec la note laissée sur son incident, quand il y en a une.

Rien de sensible n'est exposé : les visiteurs voient le nom du projet et les résultats de sonde, jamais l'URL sondée, les tokens ni aucune donnée applicative. Désactiver la page conserve le token : la réactiver restaure la même adresse, les liens déjà partagés restent valides.

Badge embarquable

Le même token sert aussi un badge SVG plat sur /status/{token}/badge.svg : vert avec la disponibilité sur 7 jours quand le site est en ligne, rouge « down » pendant une panne, gris « n/a » avant la première vérification. Glissez-le dans un README :

![uptime](https://votre-monitor.example/status/{token}/badge.svg)

Le snippet exact, avec votre vrai token, s'affiche sous l'interrupteur de la page de statut dans les Réglages du projet. Le badge se rafraîchit avec le même cache d'une minute que la page.