Uptime Kuma est un outil de supervision open source et auto-hébergé pour les vérifications HTTP(S), TCP, ping, DNS, WebSocket et autres. Installé sur un VPS distinct, il continue de surveiller quand votre serveur de production tombe, au lieu de disparaître avec lui.
Cette installation d'Uptime Kuma sur VPS déploie la v2 avec Docker Compose, garde le port 3001 sur la boucle locale, ajoute HTTPS via Caddy, achemine les alertes vers Telegram, Discord et Slack, et publie une page de statut.
Prérequis et ce dont vous aurez besoin
- Un VPS avec au moins 1 vCPU, 1 Go de RAM et 10 Go de stockage SSD local
- Ubuntu 24.04 LTS ou une autre version récente d'Ubuntu prise en charge par Docker
- Docker Engine et Docker Compose installés sur le VPS
- Un domaine ou sous-domaine pointant vers le VPS via un enregistrement A (par exemple status.example.com)
- Un accès SSH et une aisance de base avec la ligne de commande
Si Docker n'est pas encore installé, suivez le guide d'installation Ubuntu de Docker. Il installe Docker Engine et le plugin Compose utilisé ci-dessous.
Pourquoi le VPS de supervision doit être séparé de ce qu'il surveille
La production et la supervision sur un même serveur partagent le même domaine de panne. Si ce serveur s'arrête, l'application et le système chargé d'envoyer l'alerte disparaissent en même temps.
Deux dispositions concrètes améliorent la situation :
- Même fournisseur, emplacement différent. Placez la production et la supervision sur des hôtes distincts, dans des emplacements différents. Cela réduit l'exposition à une panne d'un seul serveur ou d'un seul datacenter, mais ne protège pas de tous les incidents réseau ou de plan de contrôle à l'échelle du fournisseur.
- Un fournisseur totalement différent. Héberger la supervision ailleurs protège aussi des incidents touchant tout le fournisseur. En contrepartie, cela fait un compte, une facture et une surface d'exploitation de plus à gérer.
Une instance Uptime Kuma isolée n'a toujours aucune surveillance extérieure. Ajoutez une vérification HTTP(S) externe sur sa page de statut publique. L'offre gratuite d'UptimeRobot inclut actuellement 50 moniteurs à intervalles de cinq minutes. Cela ne rendra pas Uptime Kuma hautement disponible, mais cela vous préviendra quand la supervision elle-même disparaît.
La même règle vaut pour les pages de statut publiques : ce qui vous signale la panne ne doit pas partager son domaine de panne avec ce qui tombe.
Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.
Voir les plans LinuxDimensionner le VPS
Il n'existe pas de formule fiable reliant le nombre de moniteurs à la RAM dans Uptime Kuma, car la charge dépend du type de moniteur, de l'intervalle, des réglages de nouvelle tentative et de la rétention de l'historique. Les vérifications simples HTTP(S), TCP, ping et DNS sont plus légères que les vérifications Browser Engine, qui lancent Chromium.
Pour un petit ensemble de vérifications de base, commencez avec 1 vCPU, 1 Go de RAM et du stockage SSD local. Surveillez la consommation réelle avec docker stats uptime-kuma et la croissance de la base de données avec du -sh /opt/uptime-kuma/data. Ajoutez de la mémoire quand la consommation reste élevée, quand le conteneur signale un OOM kill, ou quand vous introduisez des vérifications Browser Engine.
L'image v2 complète inclut Chromium et une base MariaDB intégrée ; la documentation des tags Docker explique la différence entre les images complète et slim.
Déployer Uptime Kuma avec Docker Compose
Enregistrez ce fichier sous docker-compose.yml dans /opt/uptime-kuma/ :
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
restart: unless-stopped
ports:
# Bind to localhost only. The reverse proxy will expose it on 443.
- "127.0.0.1:3001:3001"
volumes:
- ./data:/app/data
Trois lignes méritent qu'on s'y arrête :
- image: louislam/uptime-kuma:2 fige la version majeure. Le tag :2 suit la branche stable 2.x. N'utilisez pas :latest.
- 127.0.0.1:3001:3001 lie le conteneur à localhost uniquement. Internet ne doit jamais atteindre directement le port 3001. C'est le reverse proxy qui détient le certificat TLS et le nom d'hôte public.
- Le volume data contient la base de données, la configuration des moniteurs et l'historique. Gardez-le sur du stockage local, car la documentation d'installation d'Uptime Kuma avertit que les systèmes de fichiers sans verrouillage POSIX fiable, dont beaucoup de configurations NFS, peuvent corrompre SQLite. Arrêtez la stack avant de faire une copie au niveau du système de fichiers.
Démarrez la stack et vérifiez :
sudo install -d -o "$USER" -g "$USER" /opt/uptime-kuma
cd /opt/uptime-kuma
# Paste the docker-compose.yml file above.
sudo docker compose up -d
sudo docker compose ps
Sortie attendue de docker compose ps :
NAME IMAGE STATUS PORTS
uptime-kuma louislam/uptime-kuma:2 Up (healthy) 127.0.0.1:3001->3001/tcp
Pour accéder au tableau de bord la première fois, n'ouvrez pas le port 3001 sur Internet, même brièvement. Passez par un tunnel SSH :
ssh -L 3001:127.0.0.1:3001 [email protected]
Ouvrez http://localhost:3001 dans votre navigateur, créez le compte administrateur, choisissez un mot de passe solide, fermez le tunnel. À partir de là, le tableau de bord vous parvient en HTTPS via votre reverse proxy.
Si vous n'avez pas besoin de passer par Compose à la main, nous proposons aussi Uptime Kuma en application en un clic. La fiche actuelle indique la v1, elle ne correspond donc pas à l'installation v2 décrite ici. Passez par Compose à la main si vous avez précisément besoin de la v2.
Reverse proxy et TLS
N'exposez pas Uptime Kuma directement. Placez un reverse proxy devant lui pour le TLS, une gestion correcte des URL et un point d'entrée public unique. Deux options.
Caddy. Si Caddy n'est pas encore installé, suivez la procédure officielle des paquets Ubuntu. Avec Caddy en service sur l'hôte, le Caddyfile ci-dessous relaie vers Uptime Kuma sur la boucle locale et gère l'émission et le renouvellement du certificat automatiquement.
Astuce : quand le VPS de supervision n'héberge qu'Uptime Kuma, utilisez Caddy. Le Caddyfile tient en trois lignes, et Caddy gère l'émission et le renouvellement du certificat automatiquement. Pas de Certbot, pas de timer de renouvellement à surveiller à 4 h du matin.
Enregistrez ceci dans /etc/caddy/Caddyfile :
status.example.com {
reverse_proxy 127.0.0.1:3001
}
Rechargez Caddy :
sudo systemctl reload caddy
Vérifiez :
curl -I https://status.example.com
Vous devriez obtenir une réponse 2xx ou 3xx avec un certificat valide. Si la connexion échoue, vérifiez que l'enregistrement A ou AAAA du domaine pointe vers ce VPS, que les ports 80 et 443 sont joignables et que Caddy peut se lier aux deux. Cela fait partie des prérequis du HTTPS automatique de Caddy.
Nginx Proxy Manager. Si NPM tourne directement sur l'hôte, ajoutez un Proxy Host pour status.example.com, redirigez-le vers 127.0.0.1 sur le port 3001, demandez un certificat Let's Encrypt et activez Websockets Support. Si NPM tourne dans Docker, 127.0.0.1 renvoie au conteneur NPM lui-même. Connectez plutôt NPM et Uptime Kuma au même réseau Docker, puis pointez le proxy host vers uptime-kuma sur le port 3001.
Acheminement des alertes : Telegram, Discord, Slack
Uptime Kuma peut acheminer un même événement de moniteur vers plusieurs canaux de notification. Configurez chaque fournisseur une fois, puis rattachez un ou plusieurs canaux à un moniteur selon qui doit recevoir l'alerte.
Les notifications se configurent globalement dans Paramètres > Notifications, puis s'attribuent à chaque moniteur. Un moniteur peut déclencher un ou plusieurs canaux. La même alerte peut partir sur Telegram pour l'ingénieur d'astreinte, sur Slack pour l'équipe et par e-mail pour la traçabilité, le tout depuis un seul événement.
Telegram
- Dans Telegram, écrivez à @BotFather et lancez /newbot. Choisissez un nom et un identifiant. BotFather vous répond avec un token de bot. Conservez-le.
- Envoyez n'importe quel message à votre nouveau bot. Ouvrez ensuite https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates dans un navigateur. Repérez le champ chat.id : c'est votre identifiant de discussion.
- Dans Uptime Kuma : Paramètres > Notifications > Configurer une notification > Telegram. Collez le token du bot et l'identifiant de discussion. Cliquez sur Tester. Vérifiez que le bot envoie bien l'alerte de test.
- Si le message de test n'arrive pas, vérifiez que le token du bot et l'identifiant de discussion sont corrects, et que le pare-feu du VPS autorise les connexions HTTPS sortantes vers api.telegram.org.
Discord
- Ouvrez le serveur Discord où vous voulez recevoir les alertes. Faites un clic droit sur le salon visé, puis Modifier le salon > Intégrations > Webhooks > Nouveau webhook. Donnez-lui un nom (« Uptime Kuma », par exemple), choisissez le salon, copiez l'URL du webhook.
- Dans Uptime Kuma : Paramètres > Notifications > Configurer une notification > Discord. Collez l'URL du webhook. Vous pouvez aussi définir le nom d'utilisateur et l'avatar.
- Cliquez sur Tester. Vérifiez que le webhook publie bien l'alerte de test dans le salon.
Slack
- Dans Slack, créez un Incoming Webhook pour le canal où vous voulez recevoir les alertes. Slack vous renvoie une URL de webhook de la forme https://hooks.slack.com/services/T.../B.../....
- Dans Uptime Kuma : Paramètres > Notifications > Configurer une notification > Slack. Collez l'URL du webhook. Vous pouvez aussi configurer l'icône et le salon de remplacement.
- Cliquez sur Tester.
Une fois que tous les tests passent, modifiez chaque moniteur et choisissez les canaux de notification qu'il doit utiliser. Réglez Max Retries (nombre maximal de tentatives) et Retry Interval (intervalle entre tentatives) de sorte qu'une panne brève ne déclenche pas immédiatement une alerte.
La page de statut intégrée (et quand elle ne suffira plus)
Uptime Kuma propose des pages de statut publiques avec slugs personnalisés, moniteurs groupés, domaines personnalisés, publications d'incidents et messages de maintenance planifiée. Vous pouvez aussi publier plusieurs pages de statut depuis une même instance, pour différents services ou publics.
Sa principale limite touche la communication client. Les visiteurs ne peuvent pas encore s'abonner par e-mail aux mises à jour directement depuis une page de statut, et cette page publique fait toujours partie de la même application Uptime Kuma que le tableau de bord de l'exploitant. L'auto-inscription des visiteurs reste suivie comme une demande de fonctionnalité ouverte.
Si vous avez besoin d'abonnements clients ou d'un système de statut séparé du tableau de bord de supervision, Kener est une alternative. Notre guide sur la stack de supervision auto-hébergée explique comment associer les deux outils.
Problèmes courants
Les notifications échouent en silence quand le pare-feu du VPS bloque le HTTPS sortant. Symptôme : le bouton Test fonctionne pour certains canaux, pas pour d'autres. Correctif : vérifiez que les connexions HTTPS sortantes sont autorisées et que curl -I https://api.telegram.org réussit depuis le VPS.
Le navigateur affiche « ERR_TOO_MANY_REDIRECTS » après l'activation du proxy. Cherchez des redirections HTTP vers HTTPS en double dans Caddy, Nginx Proxy Manager ou un CDN en amont. Uptime Kuma doit continuer à servir en HTTP sur le port 3001, pendant que le reverse proxy public termine le TLS. Si vous activez les en-têtes de proxy de confiance, le chemin actuel est Paramètres > Reverse Proxy > En-têtes HTTP > Trust Proxy.
Le conteneur redémarre toutes les quelques minutes. Vérifiez si le conteneur a été arrêté par manque de mémoire, puis surveillez sa consommation actuelle avec docker stats uptime-kuma. Si le conteneur a été tué par l'OOM ou si la mémoire reste proche de la limite du VPS, ajoutez de la RAM, réduisez les vérifications lourdes ou espacez leurs intervalles.
La page de statut fonctionne en localhost mais pas via le nom d'hôte public. Vérifiez que le reverse proxy transmet le chemin racine tel quel, conserve l'en-tête Host et prend en charge les WebSockets. Uptime Kuma ne gère pas l'installation dans un sous-répertoire : utilisez donc un domaine ou sous-domaine dédié plutôt qu'un chemin du type example.com/uptime-kuma.
Pour conclure
Uptime Kuma sur un VPS distinct vous donne la main sur les vérifications, l'acheminement des alertes et la page de statut publique, mais vous héritez aussi des mises à jour, des sauvegardes, des correctifs système et de la surveillance externe du moniteur. Choisissez un VPS dans un emplacement différent de la production, déployez la v2 avec Docker Compose ou utilisez l'application en un clic après avoir vérifié la version annoncée, placez Caddy devant, et branchez les canaux que votre équipe surveille.
Foire aux questions
De combien de RAM Uptime Kuma a-t-il besoin ?
Il n'existe pas de formule fiable reliant le nombre de moniteurs à la RAM dans Uptime Kuma, car la consommation varie selon le type de moniteur, l'intervalle de vérification, les réglages de nouvelle tentative, la rétention de l'historique et l'usage du Browser Engine. Pour un petit ensemble de vérifications de base, commencez avec 1 Go de RAM et surveillez la consommation réelle avec docker stats uptime-kuma. Ajoutez de la mémoire si la consommation reste proche de la limite ou si le conteneur est tué par l'OOM.
Faut-il faire tourner Uptime Kuma sur le même serveur que mon application ?
Non. Si l'outil de supervision et l'application partagent un serveur, une panne les met hors ligne en même temps et vous perdez les alertes au moment où vous en avez le plus besoin. Faites tourner Uptime Kuma sur un VPS distinct, idéalement dans un autre datacenter.
Uptime Kuma peut-il envoyer des alertes vers Telegram, Discord et Slack ?
Oui. Telegram, Discord et Slack font partie des services de notification intégrés, aux côtés de l'e-mail, des webhooks génériques, de PagerDuty, ntfy, Mattermost et de bien d'autres. Telegram utilise un token de bot et un identifiant de discussion, tandis que Discord et Slack passent par des URL de webhook. Vous pouvez rattacher plusieurs canaux de notification à un même moniteur.
Quelle est la différence entre Uptime Kuma et UptimeRobot ?
Uptime Kuma est auto-hébergé : vous gérez donc le serveur, les mises à jour, les sauvegardes et l'acheminement des alertes. Il accepte des intervalles de vérification descendant jusqu'à 20 secondes. UptimeRobot est un SaaS hébergé, et son offre gratuite actuelle inclut 50 moniteurs avec des vérifications toutes les cinq minutes. Choisissez Uptime Kuma si vous voulez le contrôle, ou UptimeRobot si vous ne voulez pas exploiter le serveur de supervision.
Uptime Kuma propose-t-il une page de statut publique ?
Oui. Vous choisissez quels moniteurs sont visibles, vous les regroupez, vous publiez plusieurs pages de statut, vous les associez à des domaines personnalisés et vous planifiez des messages de maintenance. L'auto-inscription des visiteurs par e-mail n'est pas intégrée : utilisez donc un outil de page de statut dédié aux clients lorsque ceux-ci doivent s'abonner aux mises à jour.
