Dans cet article
Un moniteur sur le même serveur que l'application peut disparaître avec le problème. Placez Uptime Kuma ailleurs, puis testez l'alerte avec une panne contrôlée.
Décider ce que ce moniteur peut prouver
Placez Uptime Kuma sur un serveur distinct du site surveillé. Une panne du serveur applicatif ne doit pas arrêter le moniteur. Deux Droplets chez le même fournisseur ne couvrent toutefois pas une panne générale du fournisseur.
Avant création, prévoyez le coût d’un serveur distinct et des sauvegardes. Le 8 octobre 2026, les tarifs Basic forfaitaires indiquent 6 USD/mois pour 1 Gio et 12 USD/mois pour 2 Gio ; ce n’est pas une capacité testée pour votre nombre de sondes. Les sauvegardes Basic ajoutent 20 % en hebdomadaire ou 30 % en quotidien, soit 7,20 ou 7,80 USD pour l’exemple à 6 USD, hors taxes, domaine, stockage et transfert supplémentaires. Vérifiez région et configuration avant création ; les configurations v5 ont une facturation horaire distincte.
Arrêt de sécurité avant l’initialisation : le compagnon figé expose Caddy publiquement au démarrage de la pile complète. HTTPS et la fermeture du port direct 3001 ne limitent pas les personnes pouvant créer le premier compte via Caddy. Ce guide ne fournit pas encore de séquence privée d’initialisation/ACME testée. Ne créez pas de serveur et ne démarrez pas cette pile comme une installation publique prête à l’emploi ; préparez et validez d’abord l’accès réservé au propriétaire décrit ci-dessous, sur une instance jetable autorisée.
Créer et restreindre le serveur de supervision
Créez un Droplet Ubuntu 24.04 LTS neuf. Une région proche du site réduit la latence; une autre région vérifie un trajet réseau différent. Choisissez selon le trajet que vous souhaitez surveiller.
- Dans DigitalOcean, créez un Droplet avec une clé SSH. Nommez-le selon son rôle, par exemple uptime-kuma-monitor.
- Créez un Cloud Firewall réservé à ce Droplet. Gardez TCP 80 et 443 fermés en entrée pendant l’initialisation du premier compte. N’ouvrez l’accès public nécessaire au certificat et au tableau de bord qu’après validation du contrôle privé ci-dessous. Autorisez TCP 22 seulement depuis votre adresse d'administration ou votre VPN.
- Créez un enregistrement A ou AAAA pour le tableau de bord vers l'adresse publique du Droplet. Attendez sa résolution avant de lancer Caddy, qui utilise ce nom pour obtenir un certificat public.
- N'ouvrez pas le port 3001 d'Uptime Kuma dans le pare-feu. Le fichier Compose compagnon le garde sur le réseau Docker interne et Caddy reste le seul service public.
Depuis le terminal de votre ordinateur, remplacez VOTRE_IP_DROPLET par l’adresse publique du Droplet de supervision, puis ouvrez la connexion SSH avec la clé configurée lors de sa création.
ssh root@VOTRE_IP_DROPLET
Les commandes du bloc suivant s’exécutent sur le Droplet, dans cette session SSH root.
apt-get update
apt-get install -y docker.io docker-compose-v2 git nano python3
systemctl enable --now docker
docker compose version
cd /root
Déployer une app Next.js avec des aperçus de pull request
Démarrer Uptime Kuma derrière HTTPS
Les commandes suivantes s'exécutent dans le terminal SSH root ouvert à l'étape précédente. Dans Nano, enregistrez avec Ctrl+O puis Entrée et quittez avec Ctrl+X avant de continuer.
Le dépôt compagnon garde la configuration courte. Uptime Kuma stocke son état dans ./data. Caddy écoute sur les ports 80 et 443 et relaie vers le conteneur Uptime Kuma. La configuration utilise l'image officielle avec son étiquette de version majeure. Consultez les notes de mise à jour du projet avant de la modifier.
Uptime Kuma indique que ses données doivent rester sur un répertoire ou volume local, jamais NFS. Gardez-les sur le disque local du Droplet et incluez-les dans votre plan de sauvegarde.
Si le contrôle du tableau de bord échoue, vérifiez d’abord que le DNS pointe vers ce Droplet et que le Cloud Firewall est attaché. Inspectez ensuite l’état du service concerné. N’ouvrez pas le port 3001 comme raccourci : cette configuration le garde volontairement privé derrière Caddy ; l’exposer changerait la limite de sécurité au lieu de prouver l’installation.
Le dépôt est figé à 941abf472a35 et vise Uptime Kuma version majeure 2. Ses étiquettes d’image louislam/uptime-kuma:2 et caddy:2 restent mobiles. Cette relecture ne fournit pas de digest testé. Pour rendre l’essai reproductible, consignez les identifiants/digests des images et figez-les dans le déploiement ; refaites les essais après changement. Le guide officiel exige un stockage local et exclut NFS. Conservez ./data et lisez la procédure de mise à jour avant de télécharger et recréer les conteneurs.
git clone https://github.com/TylorMayfield/uptime-kuma-droplet-monitor.git
git -C uptime-kuma-droplet-monitor checkout --detach 941abf472a350a6c934d7590fd473dc45ea203ea
test "$(git -C uptime-kuma-droplet-monitor rev-parse HEAD)" = 941abf472a350a6c934d7590fd473dc45ea203ea
cd uptime-kuma-droplet-monitor
cp .env.example .env
nano .env # Définissez KUMA_DOMAIN avec le nom DNS créé.
chmod 700 scripts/preflight.sh scripts/check-dashboard.sh
./scripts/preflight.sh
Contrôle obligatoire d’initialisation privée
Arrêtez-vous après la configuration ci-dessus. Le compagnon inchangé ne fournit pas ce contrôle et son preflight ne prouve pas que l’accès est privé. Gardez Caddy public arrêté et les ports 80/443/3001 inaccessibles depuis Internet jusqu’à l’établissement du propriétaire. Faites préparer par un opérateur un point d’écoute Kuma local avec un tunnel SSH, ou un accès équivalent réservé à l’administrateur, puis tester les liaisons Compose résolues avec les digests d’images exacts enregistrés. Aucune commande d’override ou de démarrage non testée n’est fournie ici.
Avec des données jetables neuves, vérifiez que l’accès privé prévu fonctionne et qu’un client extérieur ne peut pas atteindre la création de compte. Créez le premier administrateur uniquement par cette voie privée, puis vérifiez la connexion authentifiée du compte attendu et un redémarrage. Si l’initialisation a déjà été effectuée de façon inattendue, arrêtez-vous et enquêtez ou repartez d’un état de confiance ; ne faites pas confiance à un compte inconnu.
Après ces contrôles seulement, validez le passage à l’accès prévu au tableau de bord et l’obtention du certificat Caddy. Les challenges publics HTTP/TLS de Caddy exigent l’accessibilité réseau documentée ; une liste d’adresses autorisées qui bloque ces challenges ne constitue pas une procédure TLS complète. Consignez les contrôles d’initialisation, d’exposition, d’ACME et de refus d’une nouvelle création de compte non authentifiée avant de poursuivre. Gardez la restriction privée jusqu’à ce que cette transition ait été répétée. Une page d’état publique reste un choix distinct.
Créer un moniteur et une notification avant d'en ajouter d'autres
Continuez seulement après validation de l’initialisation privée. Connectez-vous à https://KUMA_DOMAIN avec le compte administrateur déjà créé par cette voie privée. Considérez-le comme un tableau de bord privé. Une page d'état publique est un choix distinct et peut révéler des noms de services ou l'historique des pannes.
Ajoutez une méthode de notification que vous pouvez tester. Ajoutez ensuite un moniteur HTTP(s) pour une URL de santé inoffensive, définissez le code attendu et associez la notification. Commencez avec un seul moniteur.
- Envoyez le test de notification d'Uptime Kuma et confirmez que la bonne personne ou le bon canal le reçoit.
- Créez un moniteur HTTP(s) pour une URL de santé qui renvoie une réponse prévisible sans modifier l'état de l'application.
- Choisissez un délai et des nouvelles tentatives qui correspondent au service. N'utilisez pas un délai minuscule seulement pour animer le tableau de bord.
- Donnez au moniteur un nom qui décrit la panne, par exemple Vérification HTTPS du site.
Prouver l'alerte et la reprise sans arrêter la production
Après validation de l’initialisation privée et de TLS, créez dans Uptime Kuma un moniteur HTTP temporaire visant http://host.docker.internal:8099 avec le statut attendu 200 et votre notification activée. Pour ce test, ajoutez extra_hosts: ["host.docker.internal:host-gateway"] au service Uptime Kuma de votre fichier Compose, puis recréez-le. Le petit serveur ci-dessous écoute sur l'hôte; le Cloud Firewall garde 8099 fermé à Internet. Sa réponse sera 503 avant la reprise.
Enregistrez le code Python dans /root/kuma-test-target.py. Dans un second terminal SSH, lancez python3 /root/kuma-test-target.py et gardez-le ouvert. Attendez la notification de panne. Dans le premier terminal, créez /tmp/kuma-test-healthy avec touch /tmp/kuma-test-healthy. Attendez la notification de reprise, puis supprimez le moniteur temporaire, arrêtez Python avec Ctrl+C et supprimez le fichier témoin. Ne modifiez pas le site de production.
from http.server import BaseHTTPRequestHandler, HTTPServer
from pathlib import Path
marker = Path("/tmp/kuma-test-healthy")
marker.unlink(missing_ok=True)
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
status = 200 if marker.exists() else 503
self.send_response(status)
self.end_headers()
self.wfile.write(str(status).encode())
HTTPServer(("0.0.0.0", 8099), Handler).serve_forever()
cd /root/uptime-kuma-droplet-monitor
docker compose up -d
./scripts/check-dashboard.sh
Garder un signal utile
Relisez les moniteurs après la première fausse alerte. Si une défaillance temporaire est fréquente et inoffensive, ajustez les nouvelles tentatives ou le délai après l'avoir comprise. Ne réduisez pas au silence un moniteur parce qu'il a signalé un problème gênant.
Mettez Uptime Kuma à jour volontairement. Sauvegardez ses données locales, lisez les notes amont, récupérez l'image, recréez les services puis vérifiez une connexion, un moniteur et une notification.
L’essai de restauration doit retrouver une définition de sonde et ses réglages de notification à partir d’une copie hors serveur prise service arrêté. Démarrez la copie dans un environnement isolé bloquant les notifications sortantes, examinez les réglages, puis utilisez une destination de notification jetable pour un test panne/rétablissement. Notez commit, digests, horodatage et résultats. Un tableau de bord accessible ne suffit pas à valider la restauration.
Questions fréquentes
Uptime Kuma doit-il fonctionner sur le même serveur que mon application ?
Non. Placez-le sur un serveur séparé afin qu'une panne du serveur applicatif ne supprime pas aussi le moniteur. Cela ne prouve toujours pas la disponibilité hors du fournisseur ou de la région choisis.
Dois-je rendre le tableau de bord Uptime Kuma public ?
Non. Initialisez d’abord l’administrateur par un accès privé vérifié, puis choisissez séparément l’accès ultérieur au tableau de bord. La séquence d’initialisation privée reste un contrôle obligatoire à répéter dans ce guide. Une page d'état publique est facultative et ne doit contenir que les informations que vous souhaitez partager.
Comment tester une alerte Uptime Kuma sans risque ?
Utilisez un moniteur jetable et une cible temporaire qui renvoie une erreur. Confirmez les notifications de panne et de reprise. N'arrêtez pas un site de production seulement pour tester la notification.
Quelle est la preuve minimale que la supervision fonctionne ?
Un tableau de bord privé en HTTPS ne suffit pas. Envoyez un test de notification, puis utilisez une panne contrôlée temporaire et confirmez les notifications de panne et de reprise. Notez leur délai avant de compter sur un moniteur de production.