Héberger Uptime Kuma : surveiller vos sites et services (alternative à UptimeRobot)

Savoir qu’un site est indisponible avant que les clients ne le signalent permet de réduire le temps de réaction et de limiter l’impact d’une panne. Une simple alerte reçue quelques secondes après un échec HTTP, un port fermé ou l’expiration prochaine d’un certificat peut faire toute la différence.

Uptime Kuma est une solution open source de surveillance de disponibilité. Elle couvre les principaux besoins proposés par UptimeRobot, StatusCake ou Pingdom, mais s’installe sur votre propre serveur. Le logiciel est gratuit, sans limitation SaaS imposée, et les données de supervision restent sous votre contrôle. Pour une entreprise, une agence ou un administrateur système, cette approche facilite aussi la maîtrise de la localisation des données et la conformité RGPD.

Uptime Kuma ne remplace pas une plateforme complète d’observabilité avec métriques, traces et analyse de logs. Son rôle est plus ciblé : vérifier régulièrement qu’un service répond et envoyer une alerte lorsqu’il devient indisponible.

Le principe essentiel : séparer le monitoring de la production

Uptime Kuma doit être hébergé sur un serveur différent de ceux qu’il surveille.

Installer le monitoring sur le même VPS que votre site crée un angle mort majeur. Si ce serveur tombe, le site et Uptime Kuma deviennent indisponibles simultanément. Aucune sonde ne peut alors constater la panne ni transmettre une notification.

La bonne architecture comprend donc au minimum :

• un serveur de production hébergeant les sites et services ;
• un petit VPS indépendant réservé au monitoring ;
• idéalement, une localisation réseau extérieure à l’infrastructure surveillée.

Cette séparation permet de détecter une panne globale du serveur, une coupure réseau, un problème chez l’hébergeur ou une mauvaise configuration de pare-feu. Uptime Kuma consomme peu de ressources dans un usage classique, notamment avec quelques dizaines de sondes. Un petit VPS dédié au monitoring suffit généralement, à condition d’adapter sa capacité au nombre de contrôles et à leur fréquence.

Les VPS TalCloud répondent à ce type de besoin avec un hébergement en France, du stockage NVMe, une protection Anti-DDoS Netrix et un support humain, à partir de 4,99 € par mois.

Prérequis pour héberger Uptime Kuma

Pour suivre ce guide, prévoyez :

• un VPS distinct de votre production ;
• une distribution Linux maintenue ;
• Docker et le plugin Docker Compose (voir installer Docker sur un VPS) ;
• un nom de domaine ou un sous-domaine, par exemple monitoring.example.fr ;
• un enregistrement DNS de type A, et éventuellement AAAA, pointant vers le VPS ;
• les ports 80 et 443 accessibles pour le reverse proxy.

Vérifiez que Docker et Compose sont disponibles :

docker --version
docker compose version

Le port interne utilisé par Uptime Kuma est le port TCP 3001. Il sera limité à l’interface locale lorsque le service sera publié derrière un reverse proxy.

Déployer Uptime Kuma avec Docker Compose

Créez un répertoire de travail :

mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma

Ajoutez un fichier compose.yaml contenant :

services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime-kuma-data:/app/data

volumes:
  uptime-kuma-data:
    name: uptime-kuma-data

Le volume uptime-kuma-data conserve la configuration, les sondes, les notifications, les utilisateurs et l’historique. Sans stockage persistant sur /app/data, ces données seraient perdues lors de la recréation du conteneur.

Démarrez le service :

docker compose up -d
docker compose ps

Consultez les journaux si le conteneur ne démarre pas correctement :

docker compose logs --tail=100 uptime-kuma

Comme le port 3001 écoute uniquement sur 127.0.0.1, Uptime Kuma n’est pas directement accessible depuis Internet. Pour un premier test depuis le serveur, utilisez :

curl -I http://127.0.0.1:3001

Effectuer le premier accès et créer le compte administrateur

Une fois le reverse proxy configuré, ouvrez l’adresse choisie dans un navigateur. Uptime Kuma affiche son assistant initial et demande la création du compte administrateur.

Utilisez un mot de passe long et unique. Activez également l’authentification à deux facteurs depuis les paramètres du compte. Ce tableau de bord contient des informations sensibles sur votre infrastructure, notamment les domaines, les ports, les adresses IP et les canaux d’alerte.

Le compte créé lors de cette étape administre toute l’instance. La page de statut publique sera accessible séparément et ne nécessitera pas de donner accès à cette interface.

Créer les premières sondes

Dans le tableau de bord, ajoutez un nouveau moniteur et sélectionnez le type de contrôle adapté.

Une sonde HTTP(s) vérifie qu’une URL répond avec un code attendu. Elle convient aux sites, API, interfaces d’administration et points de contrôle applicatifs. Une sonde par mot-clé va plus loin en recherchant un texte précis dans la réponse. Elle peut détecter une page qui renvoie un code HTTP valide tout en affichant un message d’erreur.

Les autres contrôles courants sont :

• TCP Port pour vérifier qu’un service écoute, par exemple SSH, SMTP ou une base exposée volontairement ;
• Ping pour tester la réponse réseau d’un hôte ;
• DNS pour contrôler la résolution d’un nom ou la présence d’un enregistrement ;
• HTTP(s) avec suivi du certificat TLS pour être alerté avant son expiration.

Choisissez ensuite l’intervalle de vérification. Une fréquence de 60 secondes constitue un point de départ raisonnable pour un service important. Des contrôles trop fréquents augmentent le trafic et peuvent déclencher des protections applicatives. Configurez aussi plusieurs tentatives avant incident afin d’éviter une alerte sur une perte réseau isolée.

Pour un parcours critique, créez plusieurs sondes complémentaires. Une page d’accueil disponible ne garantit pas nécessairement que l’API, le paiement ou l’espace client fonctionne.

Configurer et tester les notifications

Uptime Kuma prend en charge de nombreux canaux, notamment Discord, Telegram, Slack, l’email SMTP et les webhooks. Le bon choix dépend du circuit d’astreinte de l’équipe.

Associez au moins un canal de notification à chaque sonde importante. Pour les services critiques, utilisez deux canaux indépendants, par exemple un webhook vers la messagerie interne et un email. Si un fournisseur de notification rencontre lui-même une panne, le second canal conserve une chance de transmettre l’alerte.

Après avoir renseigné les identifiants ou l’URL du webhook, utilisez le bouton de test intégré. Vérifiez la réception réelle du message, puis provoquez si possible une panne contrôlée sur une sonde non critique. Ce test valide toute la chaîne, depuis la détection jusqu’au retour à l’état opérationnel.

Ne placez jamais un secret de bot ou un webhook dans un dépôt Git. Limitez également les droits des comptes utilisés pour envoyer les alertes.

Publier une page de statut

La fonction Status Page permet de communiquer publiquement l’état des services sans ouvrir le tableau de bord d’administration. Créez une page, choisissez un identifiant lisible, puis ajoutez les sondes que les clients doivent voir.

Vous pouvez regrouper les composants par produit, environnement ou région. N’affichez pas les moniteurs internes contenant des noms d’hôtes, des adresses privées ou des détails techniques sensibles.

La page sera disponible sous une adresse ressemblant à :

https://monitoring.example.fr/status/services

Elle peut devenir le point de référence pendant un incident. L’équipe peut y publier une maintenance ou un message explicatif, tandis que les clients suivent le rétablissement des composants concernés.

Activer HTTPS avec un reverse proxy

Placez Uptime Kuma derrière Caddy, Nginx ou Traefik. Avec Caddy installé sur l’hôte, une configuration minimale peut prendre cette forme :

monitoring.example.fr {
    reverse_proxy 127.0.0.1:3001
}

Rechargez ensuite Caddy selon son mode d’installation :

sudo systemctl reload caddy

Le DNS doit déjà pointer vers le VPS et les ports 80 et 443 doivent être disponibles. Caddy peut alors gérer le certificat HTTPS. Avec Nginx Proxy Manager ou Nginx, pensez à transmettre correctement les connexions WebSocket utilisées par l’interface.

Conservez le port 3001 inaccessible publiquement. Le pare-feu ne doit autoriser depuis Internet que les services nécessaires, généralement SSH, HTTP et HTTPS.

Sécuriser, mettre à jour et sauvegarder l’instance

Mettez régulièrement à jour le système, Docker, le reverse proxy et l’image Uptime Kuma. Avant chaque mise à niveau, sauvegardez les données et consultez les éventuelles notes de migration.

Pour actualiser le conteneur :

cd /opt/uptime-kuma
docker compose pull
docker compose up -d
docker compose logs --tail=100 uptime-kuma

Uptime Kuma conserve notamment sa base SQLite dans /app/data. Une copie réalisée pendant une écriture peut être incohérente. La méthode la plus simple consiste donc à arrêter brièvement le service avant d’archiver le volume :

mkdir -p /opt/backups
cd /opt/uptime-kuma
docker compose stop uptime-kuma
docker run --rm -v uptime-kuma-data:/data:ro -v /opt/backups:/backup alpine sh -c 'tar czf /backup/uptime-kuma-data.tar.gz -C /data .'
docker compose start uptime-kuma

Copiez ensuite cette archive vers un stockage distinct du VPS et testez périodiquement sa restauration. Notre guide sur la stratégie de sauvegarde d’un serveur aide à l’automatiser. Surveillez enfin Uptime Kuma lui-même depuis un second point externe si le niveau de disponibilité attendu le justifie. Le résultat concret doit rester simple : une instance séparée de la production, des alertes testées, une page de statut accessible et une sauvegarde récupérable.