Un prompt peut-il remplacer Pingdom ?

Construis un monitoring de disponibilité dont la première règle de conception est qu’il ne doit pas partager le sort de ce qu’il surveille.

Stack : ton choix, SQLite suffit, Docker Compose. Le README doit s’ouvrir avec la règle de déploiement : fais tourner ça sur un fournisseur différent, dans une région différente, de l’infrastructure qu’il surveille, et dis pourquoi.

Contrôles : HTTP avec un statut attendu et une correspondance de corps optionnelle, port TCP, enregistrement DNS qui se résout vers une valeur attendue, expiration de certificat TLS en jours, et un point d’entrée heartbeat pour les tâches cron qui alerte quand une tâche ne se signale pas à temps.

Fais tourner chacun selon son intervalle, stocke chaque résultat avec le temps de réponse, et exige N échecs consécutifs avant qu’un incident ne s’ouvre — configurable par contrôle, deux par défaut, parce qu’un seul échec, c’est généralement le réseau.

Incidents : s’ouvrent au seuil d’échec, se ferment à la récupération, en stockant le début, la fin et chaque résultat entre les deux. Calcule le pourcentage de disponibilité à partir des incidents plutôt que du compte d’échantillons bruts, ce qui rend un chiffre mensuel défendable.

Alertes, avec une politique d’escalade : première notification vers un webhook, et après M minutes toujours en échec, escalade vers SMS via un fournisseur dont tu fournis les identifiants. Envoie toujours une notification de rétablissement. Déduplique pour qu’un incident envoie une alerte par canal et par étape d’escalade, et journalise chaque tentative de livraison avec la réponse du fournisseur — une alerte que tu crois avoir été envoyée et qui ne l’a pas été, c’est le pire échec possible de cet outil.

Auto-contrôle : le moniteur envoie son propre heartbeat vers un service externe gratuit, pour que la chose qui surveille tout soit elle-même surveillée. Dis dans le README que ce n’est pas optionnel.

Page de statut : rendu statique régénéré après chaque contrôle, publié sur un hébergement séparé à la fois du moniteur et du site surveillé. Montre 90 jours de statut quotidien, l’état actuel, et les incidents ouverts avec une chronologie.

Les fenêtres de maintenance suspendent les alertes mais enregistrent quand même les résultats, marqués comme tels, pour que le chiffre de disponibilité puisse être calculé des deux façons.

Écris des tests pour le seuil d’échecs consécutifs, pour la disponibilité calculée à travers un incident qui traverse minuit, pour la déduplication d’alertes, et pour les fenêtres de maintenance qui suspendent la notification mais pas l’enregistrement.

Ne construis ni monitoring d’utilisateurs réels, ni éditeur de transaction enregistré par navigateur.