Abstract purple and amber illustration representing self-hosted uptime monitoring

Uptime Kuma

Uptime Kuma est un outil de surveillance auto-hébergé, gratuit et open source : pointez-le vers un site web, une API, un serveur ou un conteneur Docker, et il interroge cette cible selon un planning, trace les résultats sous forme de graphiques, et vous alerte dès qu’un service tombe. Il tourne dans un seul conteneur Docker, derrière un tableau de bord réactif et moderne, le genre d’interface habituellement réservée à des outils payants comme UptimeRobot ou StatusCake. Aucune de ces données ne quitte le matériel que vous contrôlez.

Licence : Uptime Kuma est distribué sous licence MIT, confirmée directement depuis le fichier LICENSE du dépôt GitHub louislam/uptime-kuma, pas déduite d’un badge.

En bref : Site officiel uptime.kuma.pet · GitHub louislam/uptime-kuma, plus de 86 000 étoiles · Version actuelle 2.3.2 · Image Docker louislam/uptime-kuma sur Docker Hub, plus de 100 millions de pulls, tag recommandé :2 (la page Docker Hub du projet qualifie elle-même le tag :latest de « pratique dépréciée et déconseillée »).

Pourquoi auto-héberger sa surveillance de disponibilité ?

Les services cloud de vérification de disponibilité font le travail, mais chaque URL que vous surveillez et chaque panne que vous avez déjà eue finissent stockées sur les serveurs de quelqu’un d’autre, et les paliers gratuits plafonnent presque toujours ce que vous pouvez surveiller et à quelle fréquence. Uptime Kuma est né de ce manque : son propre README explique que son créateur voulait un outil auto-hébergé façon UptimeRobot, et que l’option la plus proche à l’époque, un projet nommé statping, était devenue instable et n’était plus maintenue. Il a donc construit le sien et l’a publié sous licence MIT en 2021. C’est depuis devenu l’un des projets les plus étoilés de l’écosystème self-hosted.

Ce qu’Uptime Kuma surveille réellement

Une seule instance couvre bien plus qu’un simple ping. Les types de moniteurs incluent HTTP(s), les ports TCP, HTTP(s) avec correspondance par mot-clé ou requête JSON, WebSocket, Ping, les enregistrements DNS, Push (pour des heartbeats externes), les serveurs de jeu Steam, et les conteneurs Docker vérifiés directement via le socket Docker, avec des intervalles pouvant descendre jusqu’à 20 secondes.

Quand quelque chose tombe, les alertes partent vers plus de 90 services de notification, dont Telegram, Discord, Slack et l’e-mail. Uptime Kuma suit aussi l’expiration des certificats TLS, prend en charge l’authentification à deux facteurs, fonctionne derrière un proxy, et peut publier plusieurs pages de statut publiques rattachées chacune à leur propre domaine.

Installer Uptime Kuma avec Docker

Le projet publie une image officielle sur Docker Hub, passée les 100 millions de pulls. Le format de paquetage utilisé, popularisé par Docker après une simple lightning talk en 2013 (notre rétrospective sur l’histoire de Docker raconte comment ce standard s’est imposé), permet à Uptime Kuma de tourner à l’identique sur un Raspberry Pi ou un serveur de production. Une seule commande suffit pour obtenir une instance fonctionnelle :

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

Pour une installation destinée à durer, le docker-compose.yaml du projet lui-même est le point de départ le plus propre :

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    ports:
      - "3001:3001"
docker compose up -d

Dans les deux cas, Uptime Kuma devient accessible sur http://ip-de-votre-serveur:3001. Un détail sur le tag : la page Docker Hub du projet recommande :2 plutôt que :latest, qu’elle qualifie elle-même de « pratique dépréciée et déconseillée », et une variante plus légère, :2-slim, existe aussi.

Évitez les systèmes de fichiers réseau pour le volume de données. La documentation officielle d’installation est explicite : « les systèmes de fichiers comme NFS ne sont PAS pris en charge », il faut mapper un répertoire local ou un volume Docker à la place, sous peine de voir la base SQLite sous-jacente se corrompre.

Premier lancement : compte admin et premier moniteur

  • Ouvrez http://ip-de-votre-serveur:3001. Uptime Kuma ne fournit aucun identifiant par défaut ; vous définissez vous-même le nom d’utilisateur et le mot de passe administrateur dès la première visite.
  • Cliquez sur Add New Monitor, choisissez un type (HTTP(s) par défaut), pointez-le vers une URL ou un hôte, réglez un intervalle de vérification, puis enregistrez.
  • Allez dans Settings → Notifications et connectez au moins un canal, Telegram, Discord ou e-mail, avant d’en avoir réellement besoin.
  • Activez l’authentification à deux facteurs dans Settings → Security si le tableau de bord doit un jour être accessible hors de votre réseau local.
  • Optionnel : ajoutez une Status Page pour une vue publique ou familiale qui n’expose pas le tableau de bord d’administration.

Matériel : Uptime Kuma tourne léger, avec une base SQLite embarquée par défaut et aucun conteneur de base de données séparé à gérer. Un Raspberry Pi, un vieux mini PC ou un cœur disponible sur un NAS encaisse sans peine des dizaines de moniteurs à intervalles de 20 secondes. Vous hésitez encore sur quel matériel utiliser ? Notre guide complet pour monter votre premier homelab détaille les compromis.

Cas d’usage en homelab

Le premier réflexe évident, c’est de surveiller tout ce qui tourne déjà ailleurs : Home Assistant, la résolution DNS de Pi-hole ou AdGuard Home, une instance Jellyfin ou Nextcloud, tout ce qui a une adresse IP. Un seul tableau de bord devient l’endroit qui montre ce qui fonctionne réellement, plutôt que de découvrir qu’un service est mort le jour où vous essayez de l’utiliser.

Les notifications ne s’arrêtent pas à un message de chat. Un webhook pointé vers n8n transforme une alerte de panne en workflow complet : redémarrer un conteneur, journaliser l’incident, escalader différemment la nuit. Une page de statut publique est aussi un moyen propre de prévenir la famille qu’un service partagé est indisponible, sans lui donner accès au tableau de bord. Face à Grafana, la différence est nette : l’un dit si un service est up en ce moment, l’autre dit comment il a évolué dans le temps, et les deux tournent souvent côte à côte dans un même homelab.

Uptime Kuma : avantages et inconvénients

  • Gratuit et open source sous licence MIT, aucun palier payant, aucune limite de moniteurs au-delà de votre propre matériel
  • Tableau de bord rapide et temps réel via WebSocket, plutôt qu’une page qui se recharge toutes les quelques minutes
  • Large éventail de protocoles pris en charge (HTTP(s), TCP, DNS, Ping, Docker, serveurs Steam) plus de 90 intégrations de notification
  • Conteneur unique avec base de données embarquée, rien d’autre à provisionner pour un premier déploiement
  • Aucune haute disponibilité intégrée ; une instance qui surveille votre homelab devient un angle mort si ce homelab perd le courant
  • Les pages de statut publiques ont besoin de votre propre nom de domaine pour paraître pleinement professionnelles
  • Plus de 90 intégrations rendent la liste de notifications longue à parcourir la première fois
  • Aucune application mobile officielle ; consulter le statut passe par le tableau de bord web ou un client tiers

Des alternatives à connaître

UptimeRobot et StatusCake restent les alternatives cloud évidentes si héberger de l’infrastructure juste pour surveiller de l’infrastructure ne vous tente pas : les deux offrent des paliers gratuits sans serveur à gérer. Le README d’Uptime Kuma crédite d’ailleurs UptimeRobot comme inspiration directe : son créateur voulait un équivalent auto-hébergé après avoir constaté que la solution la plus proche existante, statping, n’était plus maintenue.

Côté auto-hébergé, Gatus et Healthchecks.io adoptent une approche plus orientée fichier de configuration, du YAML plutôt qu’un tableau de bord. Une précision qui mérite d’être faite directement : uptimekuma.org n’est pas le site officiel, malgré un bon classement dans les résultats de recherche. Sa propre page À propos l’admet : un site de fan non officiel, sans lien avec l’auteur réel du projet. Les seuls liens officiels sont uptime.kuma.pet et github.com/louislam/uptime-kuma.

FAQ

Uptime Kuma est-il vraiment gratuit ?

Oui. Il est sous licence MIT avec le code source complet sur GitHub, aucun palier payant n’existe, et il n’y a aucune limite de moniteurs dans le logiciel lui-même, seulement ce que votre matériel peut encaisser.

uptimekuma.org est-il le site officiel ?

Non. Le dépôt GitHub du projet indique uptime.kuma.pet comme site officiel. uptimekuma.org se décrit lui-même, sur sa propre page À propos, comme un site non officiel construit par un fan, sans lien avec l’auteur.

Uptime Kuma peut-il surveiller directement des conteneurs Docker ?

Oui. Docker Containers est un type de moniteur intégré, qui vérifie l’état d’exécution d’un conteneur via le socket Docker, en plus des vérifications HTTP(s), TCP et Ping habituelles. Si ces conteneurs sont gérés via Portainer, les deux outils se complètent naturellement : l’un déploie et organise, l’autre veille à ce que tout reste up.

Uptime Kuma finit par être l’un des conteneurs isolés les plus rentables d’un homelab : une fois lancé, c’est lui qui vous dit si tout le reste fonctionne réellement. Si Home Assistant, Pi-hole, AdGuard Home ou n8n tournent déjà chez vous, les surveiller est l’affaire de cinq minutes.