Supervision sans agent, réglée depuis l'interface web
Uptime Kuma est un outil de supervision auto-hébergé sous licence MIT, écrit en JavaScript (Node.js et Vue 3). Chaque sonde se déclare dans l'interface web avec sa cible et son intervalle, 60 secondes par défaut ; sous 20 secondes, l'interface prévient que les performances peuvent en souffrir. Quand une cible ne répond plus, l'instance envoie une alerte, et les mêmes sondes alimentent les pages de statut publiques qu'elle sert elle-même.
Les contrôles partent de l'instance ou du réseau Globalping, sans rien installer sur les machines surveillées. Checkmate ajoute au contraire un agent qui remonte le CPU, la mémoire et le disque des serveurs.
Le comparatif des outils de supervision et des pages de statut auto-hébergés met Uptime Kuma face aux outils qui déclarent leurs sondes en YAML ou installent un agent sur les serveurs.
Bases de données, sondes Push et 90 canaux de notification
- Au-delà du HTTP : HTTP(s) avec mot-clé ou requête JSON sur la réponse, TCP, ping, DNS, gRPC, MQTT, Kafka, SNMP, SMTP, conteneurs Docker, et les bases PostgreSQL, MySQL/MariaDB, SQL Server, Oracle, MongoDB ou Redis.
- Des sondes passives : une sonde Push donne une URL qu'un script ou une tâche cron appelle à chaque exécution. Si l'appel n'arrive pas dans la fenêtre prévue, la sonde passe en panne.
- Plus de 90 services de notification : Telegram, Discord, Slack, Gotify, Pushover ou l'e-mail, selon le README.
- Des pages de statut détaillées : une bannière d'état global, puis les sondes en groupes repliables, chacune avec la barre de ses derniers contrôles et sa disponibilité sur 24 heures. S'y ajoutent les incidents rédigés en Markdown, avec leur historique depuis la 2.1.0, les messages de maintenance et un flux RSS. Chaque page peut avoir son nom de domaine et son CSS.
- Des fenêtres de maintenance ponctuelles, récurrentes ou en expression cron : elles suspendent les notifications des sondes concernées et s'affichent sur les pages de statut.
- Des métriques Prometheus sur
/metrics, par sonde, protégées par une clé d'API ou par les identifiants du compte.
Instance unique sans haute disponibilité, SQLite ou MariaDB
Un Uptime Robot auto-hébergé. C'est la motivation inscrite au README : son auteur cherchait un outil comme Uptime Robot à héberger lui-même, et trouvait Statping, l'un des plus proches, instable et abandonné.
Une seule instance, sans haute disponibilité. Interrogé sur des réplicas partageant une base MariaDB, un collaborateur du dépôt répond que le projet « n'est pas un système distribué » (#6394, novembre 2025), puis écrit en juillet 2026 que la haute disponibilité n'est pas prévue (#84). Le même collaborateur déconseille d'héberger la page de statut sur l'infrastructure, le datacenter ou la carte bancaire de ce qu'elle surveille.
SQLite pour les petits déploiements, MariaDB au-delà. Au premier démarrage, la v2 fait choisir la base : SQLite, que l'écran d'installation recommande « pour les déploiements de petite taille », MariaDB embarqué dans l'image Docker complète, ou un serveur MariaDB/MySQL externe. PostgreSQL n'est pas proposé (une demande est ouverte depuis septembre 2026, #7908), et aucune migration officielle ne mène d'une base SQLite à MariaDB.
Docker ou Node.js, sur disque local. Le projet documente l'image louislam/uptime-kuma:2 et une installation sous Node.js 20.4 avec pm2 ; la seule charte Helm listée pour Kubernetes est non officielle. NFS n'est pas supporté, car SQLite exige des verrous de fichiers POSIX, et la seule sauvegarde prise en charge est la copie du dossier de données.
Pas d'abonnement aux pages de statut. L'inscription des visiteurs par e-mail est demandée depuis novembre 2021 (#916) ; il leur reste le flux RSS. Cachet gère des abonnés par e-mail et demande à être hébergé à part du service qu'il annonce.
Tout se règle dans l'interface, avec un seul compte. Uptime Kuma ne lit aucun fichier de configuration (demande ouverte depuis novembre 2021, #956), et l'API Socket.io de l'interface est documentée comme interne, sans garantie de stabilité. Gatus part de l'autre bout : la supervision s'y déclare en YAML et se versionne avec le code. L'installation crée un unique compte administrateur ; la gestion de plusieurs utilisateurs est demandée depuis juillet 2021 (#128).
La sonde Docker donne la main sur l'hôte. Elle passe par le socket Docker, qui contrôle tout le démon, et le wiki déconseille alors d'exposer l'instance sur Internet ; c'est pourtant elle qui sert les pages de statut publiques.
Version 2 stable depuis octobre 2025, version 3 en préparation. La 2.0.0 est sortie le 20 octobre 2025 après un an de bêtas, la 2.5.5 le 16 septembre 2026, et la branche principale porte déjà le numéro 3.0.0-beta.0, sans version publiée. L'étiquette Docker latest, dépréciée, pointe encore sur la v1 : c'est 2 qu'il faut suivre.