Ce Qu’Uptime Kuma Fait Bien
Uptime Kuma est un excellent outil. Avec plus de 65 000 stars sur GitHub, c’est le moniteur d’uptime self-hosted le plus populaire. L’interface est propre, la mise en place est simple, et les pages de statut sont bien conçues. Pour du monitoring pur d’endpoints HTTP/TCP, il est difficile à battre.
Si votre seul besoin est “est-ce que cette URL répond ?” — Uptime Kuma est un choix solide.
La Limitation
Uptime Kuma n’est pas container-aware. Il voit des URLs, pas de l’infrastructure. Quand votre API tombe parce que PostgreSQL a crashé parce que le disque était plein, Uptime Kuma vous dit que l’API est injoignable — 20 minutes après. Mais il ne peut pas vous dire pourquoi.
Il ne sait pas :
- Quels conteneurs tournent, sont arrêtés, ou en boucle de redémarrage
- Combien de CPU, RAM ou disque chaque conteneur utilise
- Si vos images Docker ont des mises à jour de sécurité disponibles
- Si vos certificats SSL arrivent à expiration (sauf si vous ajoutez un monitor dédié)
- Si vos cron jobs s’exécutent réellement
Pour chacun de ces besoins, il faut un autre outil. Et soudain, vous jonglez entre 5 dashboards.
Qui Ne Devrait PAS Migrer
Maintenant ne remplace pas Uptime Kuma si vous :
- N’utilisez pas Docker ou Kubernetes — Maintenant est centré sur les conteneurs. Si vous monitorez des serveurs bare-metal ou des VMs sans conteneurs, Uptime Kuma est plus approprié.
- Avez besoin de 20+ canaux de notification — Uptime Kuma supporte un nombre impressionnant de services de notification. Maintenant supporte webhook, Discord (Community), et Slack, Teams, Email (Pro).
- Voulez une app mobile mature — Uptime Kuma a une UI responsive mature optimisée pour mobile. Maintenant a une PWA qui fonctionne bien sur mobile mais est plus récente.
Qui Devrait Migrer
- Utilisateurs Docker qui veulent un seul outil au lieu de Uptime Kuma + cAdvisor + Healthchecks.io + un script bash
- Self-hosters fatigués d’ajouter manuellement un monitor à chaque nouveau conteneur déployé
- Équipes qui veulent du monitoring-as-code via labels Docker plutôt que cliquer dans une UI web
Maintenant vs Uptime Kuma — Comparatif
| Fonctionnalité | Uptime Kuma | Maintenant |
|---|---|---|
| Checks HTTP/TCP | ✓ | ✓ |
| Auto-découverte conteneurs | ✗ | ✓ |
| Config par labels Docker | ✗ | ✓ |
| Monitoring état conteneurs | ✗ | ✓ |
| Métriques CPU / RAM / disque | ✗ | ✓ |
| Heartbeat / monitoring cron | Basique (push) | ✓ (start/end, durée, codes de sortie — 10 gratuits, illimités Pro) |
| Monitoring certificats SSL | ✓ (par monitor) | ✓ (auto-détecté sur endpoints HTTPS) |
| Détection mises à jour (digest OCI) | ✗ | ✓ |
| Page de statut publique | ✓ | ✓ (Pro : incidents, maintenance, abonnés) |
| Analyse sécurité réseau | ✗ | ✓ (Pro : CVE + score de risque) |
| API REST | ✓ | ✓ |
| Canaux de notification | 90+ | Webhook + Discord (gratuit), Slack/Teams/Email (Pro) |
| Self-hosted | ✓ | ✓ |
| Runtime | Node.js | Go (binaire unique) |
| RAM au repos | ~100+ Mo | ~17 Mo |
| Prix | Gratuit | Gratuit (Community) / 9 €/mois (Pro) |
Ce Que Maintenant Ajoute
Auto-découverte des conteneurs
Déployez Maintenant, et tous vos conteneurs apparaissent dans le dashboard en quelques secondes. Aucune configuration manuelle.

Monitoring HTTP/TCP par labels Docker
Configurez le monitoring directement dans votre docker-compose.yml. Pas de clics dans une UI :
labels:
maintenant.endpoint.http: "https://api.example.com/health"
maintenant.endpoint.interval: "30s"

Métriques de ressources système
CPU, RAM, réseau, disque — par conteneur et par hôte. Avec alertes sur seuils.

Monitoring heartbeat avancé
Suivez les durées des cron jobs, les codes de sortie, et détectez les jobs bloqués avec les signaux start/end.

Suivi des certificats SSL
Détection automatique sur tous les endpoints HTTPS. Alertes à 30, 14, 7, 3, 1 jour avant expiration.

Détection des mises à jour
Sachez quand des mises à jour de sécurité sont disponibles pour vos images Docker avant qu’elles ne deviennent un problème.

Migrer depuis Uptime Kuma
Ajoutez Maintenant à votre stack. Vos conteneurs sont découverts automatiquement. Ajoutez des labels Docker pour les endpoints HTTP à monitorer. Une fois satisfait, supprimez Uptime Kuma :
services:
maintenant:
image: ghcr.io/kolapsis/maintenant:latest
ports:
- "8080:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- /proc:/host/proc:ro
- maintenant-data:/data
environment:
MAINTENANT_ADDR: "0.0.0.0:8080"
MAINTENANT_DB: "/data/maintenant.db"
restart: unless-stopped
volumes:
maintenant-data:
FAQ
Puis-je faire tourner les deux pendant une transition ? Oui. Ils n’interfèrent pas l’un avec l’autre.
J’ai 50+ monitors dans Uptime Kuma. Dois-je tous les recréer ? Les conteneurs sont découverts automatiquement. Pour les endpoints HTTP/TCP, ajoutez des labels Docker à vos services. Pour les URLs externes (pas dans Docker), utilisez l’API ou le dashboard Maintenant.
Maintenant a-t-il autant de canaux de notification qu’Uptime Kuma ? Non. Uptime Kuma supporte 90+ canaux. Maintenant supporte le webhook (qui peut s’intégrer avec tout), Discord, et avec Pro : Slack, Teams et Email. Le canal webhook couvre la plupart des cas via des services comme ntfy ou Gotify.
Et la page de statut ? Les deux offrent des pages de statut publiques. Maintenant Pro ajoute la gestion d’incidents et les fenêtres de maintenance.