Uptime Kuma est l’un des outils de monitoring open source les plus populaires : une commande Docker et vous avez des checks HTTP, des alertes et des pages de statut. Pourquoi alors payer un monitoring hébergé ? Ce guide compare honnêtement les deux approches et indique quand choisir l’une ou l’autre.

1. Ce qu’Uptime Kuma fait très bien

  • Gratuit et open source (MIT), avec une communauté active.
  • Démarrage rapide : docker run -d -p 3001:3001 louislam/uptime-kuma.
  • Moniteurs HTTP(S), mot-clé, port TCP, ping, DNS, conteneur Docker et push (heartbeat).
  • Des dizaines d’intégrations de notification et des pages de statut intégrées.
  • Peut surveiller des services internes inaccessibles depuis Internet.

2. Les coûts cachés de l’auto-hébergement

Le logiciel est gratuit ; l’exploiter ne l’est pas. Il faut un serveur, un reverse proxy et TLS, des mises à jour régulières, des sauvegardes de la base SQLite/MariaDB, et quelqu’un qui remarque quand le moniteur lui-même tombe. Rien de difficile — mais c’est un service de production de plus à gérer.

3. Le vrai problème : qui surveille le surveillant ?

La plupart des instances Uptime Kuma tournent sur le même VPS, homelab ou cluster Kubernetes que les services surveillés. Quand cet hôte, son réseau, son DNS ou sa région cloud tombe, le moniteur tombe aussi — et reste muet exactement quand vous avez besoin d’une alerte. Des checks lancés depuis votre propre réseau ratent aussi les problèmes vus de l’extérieur (propagation DNS, CDN, routage).

La solution : surveiller les endpoints publics depuis l’extérieur de votre infrastructure — en hébergeant Uptime Kuma chez un autre fournisseur, ou en utilisant un service hébergé.

4. Comparatif

  • Coût : Uptime Kuma = serveur + votre temps · Hébergé = offre gratuite puis abonnement (UptimeFlux : 5 moniteurs gratuits, puis 7 $ / 19 $ / 39 $).
  • Installation : Docker + proxy + TLS · inscription et URL à coller.
  • Maintenance : à votre charge · gérée.
  • Services internes : oui · non (endpoints publics uniquement).
  • Indépendant de votre infra : seulement si hébergé ailleurs · oui par conception.
  • Équipes & workspaces : basique · intégré.

Le tableau complet est sur notre page alternative à Uptime Kuma.

5. Lequel choisir ?

Uptime Kuma si vous surveillez surtout des services internes, aimez l’auto-hébergement et disposez déjà d’un hôte séparé et fiable.

Un monitoring hébergé si vous voulez zéro maintenance, des alertes qui survivent à vos propres pannes et des pages de statut hébergées pour vos clients.

Les deux est une réponse fréquente : Uptime Kuma pour le réseau interne, un monitoring hébergé pour les sites et API publics.

6. Migrer ses moniteurs publics vers un service hébergé

  • Listez vos moniteurs publics (URL, intervalle, code ou mot-clé attendu).
  • Recréez-les dans l’outil hébergé (interface ou API) et associez les contacts d’alerte.
  • Recréez la page de statut et pointez votre sous-domaine status. dessus.
  • Laissez tourner les deux une semaine, puis supprimez les doublons.

Conclusion

Uptime Kuma est un excellent outil ; la question n’est pas les fonctionnalités mais l’endroit où vit le moniteur. Pour tout ce dont vos clients dépendent, assurez-vous qu’au moins un check tourne en dehors de votre infrastructure.

Essayez UptimeFlux gratuitement — 5 moniteurs, page de statut incluse, rien à déployer.