Uptime Kuma : votre monitoring de site web gratuit, en une soirée

L'été StartingUp poursuit sa cartographie de l'année écoulée. Après avoir containeurisé une application Next.js pour l'héberger sur son propre VPS, nous restons sur le terrain de l'indépendance d'infrastructure : cette fois, c'est le monitoring de votre site web qui passe sous votre toit, avec Uptime Kuma.

Votre site tombe un vendredi à 19 h. Qui s'en aperçoit en premier ? Dans beaucoup d'entreprises, la réponse est : un client, le lundi matin, par téléphone. Entre les deux, un week-end entier de visiteurs perdus, de formulaires muets et de doutes semés sur le sérieux de la maison. Savoir en trente secondes que votre site ne répond plus, avant vos clients, est une assurance qui coûte presque rien. Encore faut-il l'avoir souscrite.

Uptime Kuma, outil open source à héberger soi-même, offre un monitoring de site web gratuit et sans limite : vérifications HTTP jusqu'à toutes les vingt secondes, alertes sur plus de 90 canaux (Slack, Telegram, e-mail) et pages de statut publiques. Il tourne dans un simple conteneur Docker, sur un serveur d'entrée de gamme. Reste à comprendre ce qu'on installe, et les pièges que même un bon outil ne couvre pas.

Le réflexe naturel est pourtant de s'abonner à un service spécialisé : UptimeRobot, Pingdom, Better Stack et quelques dizaines d'autres font cela très bien. Mais leur modèle économique facture au moniteur et plafonne la fréquence des vérifications, alors qu'un petit serveur à quelques euros par mois fait mieux, sans compteur. Voici comment nous abordons la question, et comment monter votre propre moniteur en une soirée.

Précisons d'emblée que ces services sont sérieux, fiables, et qu'un compte gratuit chez l'un d'eux vaut infiniment mieux que rien. Le point de friction est ailleurs : tout ce qui rend la surveillance vraiment utile (vérifier plus souvent, surveiller plus de choses, alerter sur plus de canaux) fait grimper la facture. À l'heure où nous écrivons, les ordres de grandeur sont les suivants :

C'est la logique du SaaS : on paie à l'usage, et l'usage qui compte ici est précisément celui qu'on voudrait illimité. Or un moniteur d'uptime est un programme minuscule. Envoyer une requête HTTP toutes les trente secondes et regarder le code de réponse n'exige ni processeur musclé ni bande passante : le plus petit VPS du marché, à trois ou cinq euros par mois, en surveille des dizaines sans effort. La vraie question n'est donc pas de savoir si c'est techniquement possible, mais s'il existe un outil qui rende la chose aussi confortable qu'un SaaS. Il existe.

Uptime Kuma est un projet open source devenu l'une des références de l'auto-hébergement, avec une communauté très active ; la branche 2.x, arrivée en version 2.4 à l'heure où nous écrivons, en a fait un produit mature. Il sait vérifier une URL en HTTP(S), chercher un mot-clé dans une page, tester un port TCP, un ping, un enregistrement DNS ou l'état d'un conteneur Docker. Il trace l'historique et les temps de réponse, gère des fenêtres de maintenance, et publie des pages de statut publiques que vous pouvez partager avec vos clients ou votre équipe. Côté alertes, il revendique plus de 90 canaux de notification : Slack, Telegram, e-mail, Discord, SMS via divers fournisseurs, webhooks...

Sur un serveur où Docker est installé, le déploiement tient en une commande :

Ou, si vous préférez la version déclarative, un docker-compose.yml minimal :

Rendez-vous ensuite sur le port 3001 de votre serveur (idéalement derrière un reverse proxy avec HTTPS), créez le compte administrateur, ajoutez votre premier moniteur : deux minutes montre en main. Brancher Slack ou Telegram se résume à coller un webhook ou un jeton dans un formulaire, et la fréquence de vérification descend jusqu'à vingt secondes si le cœur vous en dit. Aucune des limites du tableau ci-dessus ne s'applique plus : elles n'étaient pas techniques, elles étaient commerciales.

Si même un conteneur Docker vous semble opaque, voici l'expérience qui montre qu'il n'y a aucune magie là-dedans. Un moniteur d'uptime, réduit à son essence, c'est ceci :

Déposez ce script sur n'importe quelle machine allumée en permanence, ajoutez une ligne de cron du type */2 * * * * /opt/monitor/check.sh, et vous recevez une notification sur votre téléphone (via l'application gratuite ntfy, ici) dans les deux minutes qui suivent une panne. Cinq lignes de shell : c'est le cœur du service que les plateformes facturent au moniteur.

Ce dénuement a un prix, évidemment : pas d'historique, pas de seconde tentative avant d'alerter, pas d'interface, pas de page de statut. C'est exactement la valeur qu'Uptime Kuma ajoute par-dessus. Mais avoir écrit une fois ce script change le regard : on sait désormais ce qu'on achète, et ce qu'on peut décider d'héberger soi-même.

Le piège classique du débutant : installer le moniteur sur le même serveur que le site. Quand le serveur tombe, l'alarme tombe avec lui, et personne ne sonne. Le moniteur doit vivre ailleurs : un autre VPS, idéalement chez un autre hébergeur ou dans un autre datacenter, pour que la panne de l'un n'aveugle pas l'autre. Reste la question vertigineuse : qui surveille le moniteur ? Notre réponse pragmatique : un compte gratuit UptimeRobot pointé... sur votre Uptime Kuma. L'ironie ne nous échappe pas, la redondance non plus.

Les pannes les plus bêtes ne sont pas des pannes de serveur. Un certificat TLS expiré un dimanche affiche un avertissement de sécurité à chaque visiteur : le site est « up », mais plus personne n'entre. Uptime Kuma surveille l'expiration des certificats et peut alerter plusieurs jours à l'avance : activez-le systématiquement. L'expiration du nom de domaine, elle, n'est pas couverte nativement à notre connaissance : renouvellement automatique chez le registrar, moyen de paiement à jour et rappel en amont restent la seule vraie parade. Un domaine perdu se récupère beaucoup plus difficilement qu'un serveur redémarré.

Un timeout isolé n'est pas une panne : le réseau a ses humeurs, et un site peut mettre onze secondes à répondre une fois par jour sans que cela mérite un réveil nocturne. Configurez le nombre de tentatives avant alerte (deux ou trois échecs consécutifs), espacez les renvois de notification, et résistez à la tentation de multiplier les canaux. Une alarme qui crie trop souvent finit ignorée, et une alerte ignorée est pire que pas d'alerte du tout : elle donne l'illusion d'être couvert. Mieux vaut une alerte fiable en deux minutes qu'un flux nerveux toutes les trente secondes.

Résumons l'affaire du point de vue du décideur : pour le prix d'un café par mois et une soirée d'installation, vous saurez toujours avant vos clients que votre site est tombé, votre certificat sera renouvelé avant d'expirer, et vous disposerez d'une page de statut à montrer quand on vous posera la question. Ce n'est pas un projet technique, c'est une décision de gestion des risques, et c'est probablement la mieux amortie de toutes celles que nous décrivons dans ces pages.

L'exercice a une vertu secondaire, qui nous est chère : comme pour l'hébergement de vos applications, reprendre la main sur ce maillon vous apprend ce qu'il contient réellement. Un abonnement se subit ; un outil qu'on héberge se comprend. Et le jour où votre téléphone vibre à 19 h 04 pour une panne survenue à 19 h 03, vous saurez exactement ce que valent ces quelques euros.