Uptime Kuma

Utilisations possibles

• Vérifiez sites web, API et ports TCP à intervalles réguliers et soyez averti lorsqu’ils ne répondent plus.
• Publiez une page de statut qui montre à vos utilisateurs la disponibilité de vos services.

Choisir la bonne configuration

Utilisez ce modèle pour les contrôles périodiques de disponibilité et les pages de statut. Vérifiez quels endpoints sont accessibles depuis la région et préparez les identifiants de notification. Si la sonde partage l’infrastructure des services surveillés, prévoyez un contrôle indépendant pour les pannes communes.

Ce que crée ce modèle

Configuration à vérifier

Ce modèle ne déclare aucun champ supplémentaire. Vérifiez les variables générées, les points d’accès et les ressources dans le formulaire.

Comment déployer

1. Sélectionnez Configurer le déploiement et connectez-vous ou créez un compte.
2. Choisissez un projet nouveau ou existant et une région disponible.
3. Vérifiez les services, champs obligatoires, stockage et avertissements. Lancez le déploiement lorsque la configuration est prête.
4. Consultez les journaux, terminez la configuration de l’application et testez ses points d’accès avant la production.

Vérifier votre déploiement

Créez le compte administrateur, ajoutez une sonde de test et confirmez un contrôle réussi. Envoyez une notification de test et vérifiez sa réception. Simulez une panne puis une reprise sur une cible jetable et consultez l’historique ; une sonde au vert ne prouve pas que les notifications fonctionnent.

Exploitation de cette application

• Ouvrez le domaine généré dès le déploiement et terminez la configuration d’Uptime Kuma en créant le compte administrateur, car la page de configuration reste accessible à tous jusque-là. Les notifications par e-mail ou messagerie nécessitent leurs propres identifiants SMTP ou de service.
• Les sondes, les paramètres de notification et l’historique des vérifications sont stockés dans /app/data sur le volume. Vérifiez vos options de sauvegarde et de récupération et testez une restauration avant de vous y fier.
• Le tag louislam/uptime-kuma:2 suit les nouvelles versions 2.x : lisez les notes de version avant de redéployer. Les vérifications partent de la région où le service est déployé, et une sonde hébergée avec les services qu’elle surveille peut ne pas vous alerter lors d’une panne commune.

Coûts d’hébergement

Ce modèle exécute un service avec un volume de données. Nombre de sondes, fréquence des contrôles et historique conservé influencent les besoins. Comptez séparément les frais de votre fournisseur de notifications.

CPU, mémoire, stockage et réseau contribuent à la facture. La région influe sur les tarifs. Chaque service d’un modèle génère sa propre consommation ; les API externes et licences sont facturées séparément.

Source et validation

Cette configuration provient des modèles ouverts Coolify sous licence Apache-2.0 et est adaptée par l’importateur Compose de Polyer.

L’analyse statique ne vérifie pas l’application en fonctionnement. Testez la configuration et la reprise avant de les utiliser en production.

Contenu éditorial vérifié: 2026-10-15

Documentation d’origine ↗Source et licence du modèle ↗