La comparaison du monitoring self-hosted présente Uptime Kuma comme l’outil pour une question précise : un service est-il réellement joignable en ce moment. Ce guide en est la version pratique. Depuis un seul conteneur Docker, vous obtenez la surveillance HTTP, TCP et ping, une page de statut publique que vous pouvez réellement partager, et une notification sur votre téléphone à l’instant où quelque chose cesse de répondre. Rien de tout ça ne prend une après-midi. L’essentiel prend dix minutes.
Ce qu’Uptime Kuma fait réellement
Uptime Kuma est une alternative gratuite et self-hosted à UptimeRobot et StatusCake : du monitoring en boîte noire qui ne se soucie pas de ce sur quoi tourne un service, seulement s’il répond quand on l’interroge. Il prend en charge les vérifications HTTP/HTTPS (avec correspondance optionnelle de mot-clé ou de code de statut), les vérifications de port TCP, le ping, les vérifications d’enregistrements DNS, et une liste croissante d’intégrations spécifiques comme le statut de conteneur Docker et gRPC. Sous licence MIT, développé par le même développeur que Dockge, c’est l’un des projets self-hosted les plus étoilés sur GitHub, largement au-delà des 60 000 étoiles à ce stade, ce qui en dit long sur le nombre de personnes qui ont exactement le problème « est-ce que mes services tournent » qu’il résout. Pour le détail de la licence, l’image Docker officielle, et une comparaison avec des outils similaires, voir la fiche Uptime Kuma ; le dépôt GitHub du projet vaut aussi le coup d’œil pour les notes de version et le wiki.
Installer Uptime Kuma avec Docker
Un seul conteneur suffit :
version: "3.8"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
volumes:
- uptime-kuma-data:/app/data
ports:
- "3001:3001"
volumes:
uptime-kuma-data:Lancez docker compose up -d depuis le dossier contenant ce fichier, puis ouvrez http://votre-ip-serveur:3001. La première visite demande un nom d’utilisateur et un mot de passe administrateur. Réglez-les immédiatement, puisque c’est l’interface qui contrôle chaque moniteur et chaque notification par la suite. Pas de base de données séparée à configurer, pas d’exporters à installer. Ça démarre, tout simplement.
Ajouter vos premiers moniteurs
Chaque moniteur d’Uptime Kuma suit la même structure de base : un type de moniteur, une cible, un intervalle de vérification, et un nombre de tentatives avant d’être signalé comme down. Quelques configurations courantes :
- Moniteur HTTP(s) : pointez-le vers une URL (une page d’accueil, un reverse proxy, un endpoint de santé d’API), et réglez-le éventuellement pour chercher un mot-clé précis dans la réponse ou n’accepter que certains codes de statut, pour qu’une page qui se charge mais renvoie n’importe quoi compte quand même comme down
- Moniteur de port TCP : utile pour les services qui ne parlent pas du tout HTTP, comme une base de données ou un daemon SSH, en vérifiant seulement si le port accepte une connexion
- Moniteur ping : la vérification la plus simple, adaptée aux routeurs, switches, ou tout appareil censé simplement répondre à l’ICMP
- Moniteur push : au lieu qu’Uptime Kuma vérifie une cible, c’est la cible qui appelle une URL Uptime Kuma unique selon son propre planning, utile pour les cron jobs, les scripts de sauvegarde, ou tout ce qui devrait signaler « j’ai tourné avec succès » plutôt que « je suis joignable »
L’intervalle de vérification par défaut de 60 secondes et un nombre de tentatives de 1 à 3 conviennent à la plupart des services d’un homelab. Réduire l’intervalle a du sens pour tout ce qui est vraiment critique, et l’augmenter évite de marteler quelque chose comme une API à taux limité. Chaque moniteur obtient aussi son propre journal d’événements, donc quand quelque chose tombe réellement, il y a un historique horodaté plutôt qu’un vague souvenir de « c’est arrivé un jour la semaine dernière ».
Les moniteurs peuvent aussi être tagués et groupés, ce qui devient vite utile dès qu’il y en a plus qu’une poignée qui tournent. Un tag « critique » sur le reverse proxy et le serveur DNS, associé à un intervalle de vérification plus court et une notification immédiate, évite que les alertes importantes se retrouvent noyées sous une alerte moins urgente concernant, disons, un blog personnel dont personne ne dépend activement. Uptime Kuma prend aussi en charge les fenêtres de maintenance : planifiez-en une avant de redémarrer un service ou de mettre à jour l’hôte, et les moniteurs se mettent en pause au lieu de déclencher une fausse alerte « down » pendant un arrêt planifié.
Mettre en place une page de statut publique
C’est la fonctionnalité qui distingue Uptime Kuma d’un simple tableau de bord de monitoring : une page partageable montrant le statut en direct des services sélectionnés, sans exposer l’interface d’administration elle-même.
- Allez dans Status Pages → New Status Page
- Donnez-lui un nom et un slug (ça devient une partie de l’URL publique)
- Ajoutez les moniteurs qui doivent être visibles publiquement, groupés comme ça a du sens (« Media », « Réseau », « Services Essentiels », par exemple)
- Personnalisez le titre de la page, la description, et un domaine personnalisé en option
- Publish
La page de statut publique est une vue séparée, en lecture seule. Les visiteurs voient les pourcentages de disponibilité et l’historique des incidents pour les moniteurs qui y sont ajoutés. Ils ne voient jamais le tableau de bord admin, la liste de tous les moniteurs qui tournent, ou quoi que ce soit d’autre configuré dans Uptime Kuma. Cette séparation, c’est ce qui rend sûr le fait de partager réellement le lien avec des personnes en dehors du foyer.
Plusieurs pages de statut et notes d’incident
Uptime Kuma ne se limite pas à une seule page de statut. Un schéma courant consiste à en faire tourner deux : une page publique minimale couvrant juste la poignée de services qui comptent pour les personnes en dehors du foyer, un serveur Jellyfin partagé avec la famille, disons, et une page interne plus détaillée couvrant tout, gardée privée ou partagée seulement avec qui d’autre administre le homelab. Chaque page de statut est indépendante, avec son propre slug, sa sélection de moniteurs et son style, et un domaine personnalisé (status.votredomaine.com pointé vers le même hôte) fonctionne aussi, une fois que le reverse proxy devant Uptime Kuma route ce nom d’hôte au bon endroit.
Les pages de statut prennent aussi en charge les notes d’incident : de courtes mises à jour textuelles publiées directement sur la page pendant une panne ou une fenêtre de maintenance, des choses comme « Investigation d’une latence élevée en cours » ou « Redémarrage planifié, retour vers 22h ». C’est une petite fonctionnalité, mais c’est la différence entre une page de statut qui se contente d’afficher un point rouge et une autre qui explique réellement ce qui se passe, ce qui compte si quelqu’un d’autre que vous la consulte.
Intégrations de notification : Discord, Telegram, ntfy et email
Les notifications se configurent une fois sous Settings → Notifications puis s’attachent aux moniteurs qui doivent les déclencher. Les quatre plus courantes pour un homelab :
- Discord : créez une URL de webhook dans les paramètres du canal cible, collez-la dans le type de notification Discord d’Uptime Kuma, terminé. Les messages s’affichent formatés avec le nom du moniteur et son statut.
- Telegram : créez un bot via BotFather, récupérez le token du bot, et ajoutez l’ID de chat du canal ou du DM qui doit recevoir les alertes. Un peu plus de configuration que Discord, mais tout aussi fiable.
- ntfy : un service de notification push léger et auto-hébergeable. Uptime Kuma a juste besoin de l’URL du topic, et aucun compte ni clé API n’est nécessaire si vous utilisez le serveur public ntfy.sh pour un nom de topic privé. La documentation ntfy couvre aussi son auto-hébergement, si garder les notifications entièrement hors d’une infrastructure tierce compte pour vous.
- Email : réglages SMTP standards (hôte, port, identifiants), utile comme canal de secours même si Discord ou Telegram est le canal principal.
Tester chaque type de notification immédiatement après l’avoir configuré vaut la minute supplémentaire que ça prend. Un webhook mal configuré échoue silencieusement jusqu’au moment où un service tombe réellement, ce qui est exactement le pire moment pour le découvrir.
Exposer la page de statut sans exposer le tableau de bord
La page de statut publique et le tableau de bord admin vivent derrière le même conteneur Uptime Kuma, ce qui signifie qu’exposer l’un sans précaution peut exposer les deux. Le schéma le plus sûr, celui vers lequel la plupart des homelabs finissent par se tourner : placez un reverse proxy comme Nginx Proxy Manager ou Caddy devant Uptime Kuma sur un sous-domaine public, mais restreignez l’accès au chemin /dashboard (ou à la connexion admin) à une plage IP spécifique ou à un VPN. La page de statut elle-même, à la racine ou sur /status/votre-slug, peut rester ouverte au monde puisqu’elle est en lecture seule par conception.
Pour la partie admin spécifiquement, garder le port 3001 hors d’internet et y accéder via un tunnel WireGuard est l’option la plus prudente, et c’est celle vers laquelle il vaut la peine de partir par défaut, sauf raison précise pour laquelle plusieurs personnes en dehors du réseau ont besoin d’accéder au tableau de bord.
Où ça s’intègre dans le reste de votre monitoring
Uptime Kuma répond à « est-ce que ça tourne », pas à « pourquoi c’est lent » ou « combien de RAM ça utilise ». Pour ces questions-là, il se marie naturellement avec un outil de métriques qui tourne à côté plutôt qu’à sa place. La comparaison complète de quand privilégier Uptime Kuma par rapport à Netdata ou à Prometheus et Grafana est dans le guide du monitoring self-hosted. En pratique, la plupart des homelabs qui commencent par Uptime Kuma parce que c’est le plus rapide à mettre en route finissent par ajouter l’un des outils axés métriques plus tard, une fois que « est-ce que ça tourne » cesse d’être la seule question qui mérite d’être posée.