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. Ce guide publie un tableau de bord administrateur privé derrière HTTPS. 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.

← Tous les guides GitHub

Exploitation de site

Surveiller un site web avec Uptime Kuma

31 août 2026

Exécutez Uptime Kuma sur un serveur séparé, vérifiez un site en HTTPS et prouvez qu’une alerte et sa reprise vous parviennent avant une panne.

Aller aux étapes ↓GitHub: TylorMayfield/uptime-kuma-droplet-monitor

Comment le chemin de supervision reste séparé

La vérification part d’un Droplet de supervision dédié. Le HTTPS public s’arrête à Caddy, tandis qu’Uptime Kuma et son port 3001 restent dans le réseau Docker du serveur.

Administrateur
Utilise SSH seulement depuis une adresse ou une plage VPN approuvée pour configurer le serveur de supervision dédié.
Frontière: Administration restreinte
Tableau de bord HTTPS
Caddy reçoit le trafic sur le port 443 et le transmet à Uptime Kuma dans Docker. Le port 3001 n’est pas public.
Frontière: Frontière du public au privé
URL de santé cible
Uptime Kuma vérifie une cible inoffensive depuis le Droplet séparé et enregistre le résultat.
Frontière: Vérification sortante
Destination de notification
Une panne et une reprise contrôlées envoient des messages à la destination choisie avant l’ajout d’autres moniteurs.
Frontière: Alerte sortante

Point d’attention: Cela prouve ce que le moniteur séparé peut atteindre. Un second Droplet chez le même fournisseur ne crée pas une couverture indépendante du fournisseur.

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.

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. Autorisez TCP 80 et 443 depuis Internet pour le certificat HTTPS et le tableau de bord. 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 votre ordinateur : connexion par clé SSHTerminal local
```
ssh root@YOUR_DROPLET_IP
```

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é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.

Avant de continuer : Cette procédure démarre des services HTTPS publics sur le Droplet de supervision. Confirmez l'enregistrement DNS et les règles de pare-feu avant de l'exécuter.

git clone https://github.com/TylorMayfield/uptime-kuma-droplet-monitor.git

Ouvrir le dossier
```
cd uptime-kuma-droplet-monitor
```
Créer le fichier d'environnement
```
cp .env.example .env
```
Définir le nom DNSÉditeur de fichiers
```
nano .env
```
Rendre les scripts exécutablesSur le serveur de supervision
```
chmod 700 scripts/preflight.sh scripts/check-dashboard.sh
```
Exécuter le contrôle préalable
```
./scripts/preflight.sh
```
Démarrer les services
```
docker compose up -d
```
Vérifier le tableau de bord
```
./scripts/check-dashboard.sh
```

Créer un moniteur et une notification avant d'en ajouter d'autres

Ouvrez https://KUMA_DOMAIN et créez le premier compte administrateur. 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

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()

Avant de continuer : Cette commande redémarre le tableau de bord de supervision. Exécutez-la seulement après un déploiement fonctionnel.

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.

Vérifier le résultat

Résultat attendu: Le tableau de bord est disponible en HTTPS, la notification de panne arrive après l'échec contrôlé et la notification de reprise arrive lorsque la cible réussit de nouveau.
Arrêter si: Arrêtez si le moniteur fonctionne sur le serveur applicatif, si le port 3001 est public, si le tableau de bord n'a pas de compte administrateur, si le DNS ne pointe pas vers le moniteur ou si le test de notification n'arrive pas.
Étape suivante: Consignez les délais d'alerte et de reprise, puis ajoutez le contrôle de santé de production seulement après avoir défini son URL et sa réponse attendue.