Une status page publique est un outil de communication essentiel : quand votre service tombe (ce qui arrivera), une page status.exemple.sn qui montre clairement ce qui marche et ce qui ne marche pas évite des dizaines de tickets clients et rassure votre audience. Uptime Kuma le fait gratuitement, en quelques clics. Voici le tutoriel 2026.

Voir notre guide Uptime Kuma complet.

Étape 1 — Créer une status page

Uptime Kuma → Status Pages → New Status Page
Slug : main (URL sera status.exemple.sn/status/main)
Title : ITSkillsCenter Status
Description : État en temps réel des services ITSkillsCenter
Logo : upload votre logo (recommandé)
Thème : Light ou Dark selon préférence

Étape 2 — Ajouter monitors par groupe

Organisez les monitors en groupes pour clarté :

Site web : exemple.sn, blog.exemple.sn
API : api.exemple.sn, auth.exemple.sn
Infrastructure : Postgres, Redis (HTTPS health endpoint si exposé)
Tiers : Wave API, Orange Money API (depuis Uptime Kuma vers ces endpoints)

Étape 3 — Domaine custom

Pour avoir status.exemple.sn directement (sans /status/main), configurez Uptime Kuma sur ce domaine et indiquez la status page comme page d’accueil :

Status Page → Settings → « Display this page when visiting /«
Ou Caddyfile : redirection root vers /status/main

Étape 4 — Incidents et messages

Lors d’un incident, ajoutez un message à la status page :

Edit status page → Incident → New Incident
Status : Investigating / Identified / Update / Resolved
Title et description en français
Pin to top pendant l’incident

L’historique des incidents reste visible aux visiteurs, ce qui rassure (vous communiquez, vous résolvez).

Étape 5 — Embed dans un site

Pour afficher un badge « All systems operational » sur votre site :

<iframe 
  src="https://status.exemple.sn/status/main" 
  width="100%" 
  height="600" 
  frameborder="0"></iframe>

Ou via API JSON pour custom rendering :

fetch("https://status.exemple.sn/api/status-page/main")
  .then(r => r.json())
  .then(data => { /* render custom badge */ });

Étape 6 — Multi status pages (agence)

Pour une agence avec plusieurs clients, créez une status page par client avec :

Slug et URL distincts par client
Logo et nom du client
Monitors filtrés (un seul monitor peut apparaître sur plusieurs status pages)

Adaptation Afrique de l’Ouest

Pour les PME francophones, la status page en français professionnel rassure : « Tous les systèmes sont opérationnels », « Incident en cours d’investigation ». Cloudflare Free devant pour servir la status page depuis edge proche (Lagos, Casablanca) — visiteurs depuis Sénégal/CI accèdent en < 100 ms.

Lectures complémentaires

Pourquoi exposer une status page publique avec Uptime Kuma

Une status page publique rassure clients et utilisateurs en cas d’incident. Pour une PME tech basée à Dakar, Abidjan ou Lomé qui héberge ses services sur un VPS Hetzner ou Contabo, dépenser entre 25 et 100 USD par mois pour un Statuspage.io ou un BetterStack n’a pas de sens. Uptime Kuma, projet open source mature (40 000+ étoiles GitHub, version 2.x stable en 2026), couvre 90 % du besoin gratuitement. Ce tutoriel installe Uptime Kuma, le sécurise derrière un reverse proxy Caddy, puis publie une status page en lecture seule sur un sous-domaine dédié.

Prérequis : un VPS minimal (1 vCPU, 2 Go RAM, environ 5 EUR par mois soit 3280 FCFA), Docker Engine 27+ installé, un nom de domaine pointant vers l’IP du serveur, et un accès root SSH.

Étape 1 — Préparer l’environnement Docker

Vérifiez que Docker est installé et fonctionnel avec docker --version ; la sortie doit afficher Docker version 27.x ou supérieur. Créez ensuite un dossier dédié pour les volumes persistants.

mkdir -p /opt/uptime-kuma/data
cd /opt/uptime-kuma

Ce dossier hébergera la base SQLite d’Uptime Kuma et survivra aux redémarrages du conteneur. Sans ce volume monté, toute votre configuration disparaîtrait à la première mise à jour.

Étape 2 — Lancer Uptime Kuma avec docker compose

Créez un fichier docker-compose.yml minimal et démarrez le service. La version officielle louislam/uptime-kuma:1 reste la branche stable recommandée en 2026 ; la branche 2.x est disponible mais encore marquée beta.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

Le binding 127.0.0.1:3001 est intentionnel : Uptime Kuma n’est pas exposé directement à Internet. Caddy s’occupera du TLS et de la terminaison HTTPS. Vérifiez avec docker compose ps que le conteneur est bien en état Up.

Étape 3 — Configurer Caddy comme reverse proxy

Caddy gère automatiquement les certificats Let’s Encrypt et la redirection HTTP→HTTPS. Installez-le avec apt install caddy sur Debian 12 ou Ubuntu 24.04. Éditez /etc/caddy/Caddyfile :

status.exemple.io {
    reverse_proxy 127.0.0.1:3001
    encode gzip
}

Rechargez avec systemctl reload caddy. Caddy demande automatiquement un certificat à Let’s Encrypt et redirige le trafic chiffré vers Uptime Kuma. Testez avec curl -I https://status.exemple.io ; l’en-tête HTTP/2 200 doit apparaître.

Étape 4 — Créer le compte administrateur

Ouvrez https://status.exemple.io dans un navigateur. La première visite affiche un formulaire de création du compte admin. Choisissez un identifiant peu prévisible (évitez admin) et un mot de passe long de 24 caractères stocké dans un gestionnaire comme Bitwarden ou KeePassXC. Activez immédiatement la 2FA dans Settings → Security après la première connexion.

Étape 5 — Ajouter vos premiers monitors

Cliquez sur Add New Monitor. Pour un site WordPress public, choisissez le type HTTP(s), URL https://www.exemple.io, intervalle 60 secondes, retries 2. Ajoutez un keyword présent dans le HTML pour détecter les pages blanches qui retournent 200. Pour un serveur SMTP, choisissez TCP Port, port 587. Pour une base PostgreSQL, choisissez PostgreSQL et fournissez la chaîne de connexion. Multipliez les types de monitors selon vos services.

Étape 6 — Créer une status page publique

Allez dans Settings → Status Pages → New Status Page. Donnez-lui un slug (public), un titre, un domaine personnalisé si souhaité (uptime.exemple.io via un nouveau bloc Caddy). Sélectionnez les monitors à afficher publiquement : excluez les monitors internes contenant des informations sensibles. Activez Show certificate expiry pour afficher la date d’expiration TLS, utile pour démontrer le sérieux de votre infrastructure.

Étape 7 — Configurer les notifications Telegram

Dans Settings → Notifications → Setup Notification, ajoutez un canal Telegram et un canal Email SMTP. Pour Telegram : créez un bot via @BotFather, copiez le token, démarrez une conversation avec le bot, récupérez votre chat ID via @userinfobot, collez les deux dans Uptime Kuma. Testez immédiatement avec Test. L’avantage de Telegram : gratuit, instantané, fiable même sur les réseaux mobiles ouest-africains 3G qui peuvent saturer un SMTP classique.

Étape 8 — Sauvegarder la base de données

La base SQLite se trouve dans /opt/uptime-kuma/data/kuma.db. Configurez un cron quotidien qui copie ce fichier vers un stockage hors-serveur (Backblaze B2, Wasabi, ou un second VPS).

0 3 * * * tar czf /tmp/kuma-$(date +\%F).tgz -C /opt/uptime-kuma/data kuma.db

Conservez 30 jours de sauvegardes minimum. En cas de corruption ou de compromission du serveur, vous restaurez la totalité des monitors et de l’historique en moins de cinq minutes. Pour un guide complémentaire de durcissement, consultez notre tutoriel sécurité Linux.

Étape 9 — Mettre à jour Uptime Kuma sans casser

Avant chaque mise à jour, sauvegardez la base. Puis lancez docker compose pull suivi de docker compose up -d. Le conteneur redémarre avec la nouvelle image en moins de 30 secondes. Surveillez les changelogs sur GitHub avant les montées majeures. La 1.x reste rétro-compatible ; la 2.x exigera une migration manuelle de la base — ne migrez pas en production sans tests préalables sur un environnement de staging.

Étape 10 — Surveiller Uptime Kuma lui-même

Paradoxe : qui surveille le surveillant ? Configurez un monitor externe gratuit chez UptimeRobot ou Healthchecks.io qui pingue https://status.exemple.io toutes les cinq minutes. Si votre VPS tombe, vous recevez une alerte indépendante. Cette redondance simple coûte zéro et couvre le scénario du bug logiciel d’Uptime Kuma lui-même.

Étape 11 — Personnaliser l’apparence de la status page

Dans la configuration de la status page, vous pouvez téléverser un logo, choisir un thème clair ou sombre, ajouter une description personnalisée et regrouper les monitors par catégorie (API, Site Web, Base de Données, Paiement). Pour une PME sénégalaise ou ivoirienne, le regroupement par service métier (Caisse, Facturation, Application Mobile) parle plus aux clients qu’un découpage technique. Ajoutez un footer indiquant l’email de contact incident et le délai moyen de réponse engagé.

Étape 12 — Maintenance planifiée et incidents annoncés

Uptime Kuma propose Settings → Maintenance pour déclarer une fenêtre de maintenance programmée. Pendant cette fenêtre, les monitors concernés ne déclenchent pas d’alerte et la status page affiche un bandeau orange explicite. Pour annoncer un incident en cours, utilisez la section Incidents de la status page : créez un titre court, un statut (Investigating, Identified, Monitoring, Resolved), et un message public. Mettre à jour cet incident toutes les 30 minutes maintient la confiance des utilisateurs même quand le service est dégradé.

Étape 13 — Limites et alternatives

Uptime Kuma reste un outil mono-serveur. Pour une infrastructure multi-régions ou des SLA contractuels, regardez du côté de Cachet self-hosted, ou accepter le coût de BetterStack à 29 USD par mois. Mais pour 95 % des PME ouest-africaines, Uptime Kuma sur un petit VPS est largement suffisant et tient en charge plusieurs centaines de monitors sans broncher.

Étape 14 — Intégrer Uptime Kuma à un canal Slack ou Discord

Au-delà de Telegram et de l’email, Uptime Kuma supporte plus de 90 canaux de notification natifs : Slack, Discord, Microsoft Teams, Mattermost, Rocket.Chat, Gotify, ntfy, Pushover, Pushbullet, Apprise. Pour une équipe technique qui vit dans Slack ou Discord toute la journée, recevoir les alertes dans un salon dédié #alertes-prod centralise la communication d’incident. Créez d’abord un webhook entrant côté Slack via Apps → Incoming Webhooks → Add to Slack, copiez l’URL générée, puis collez-la dans Uptime Kuma → Notifications → Slack. Personnalisez le préfixe pour distinguer prod et staging : [PROD] et [STAGING] en début de message.

Pour Discord, la procédure est similaire : créez un webhook depuis les paramètres du salon, sous Intégrations → Webhooks → Nouveau webhook. Discord limite à 30 messages par minute par webhook, ce qui couvre largement l’usage Uptime Kuma sauf en cas de tempête d’alertes massives — auquel cas le vrai problème n’est plus la limite Discord mais l’incident sous-jacent.

Étape 15 — Tags, regroupements et hiérarchie de criticité

Au-delà de quinze monitors, l’interface devient vite chargée. Utilisez les tags Uptime Kuma pour catégoriser : critique, important, secondaire, ou par client : client-cfao, client-sonatel. Les tags sont colorés et filtrables depuis le dashboard. Combinez avec un schéma de notification différencié : les monitors critique alertent Telegram + Slack + email + SMS via Twilio, les important alertent Slack uniquement, les secondaire ne notifient que dans un salon de veille. Cette gradation évite la fatigue d’alerte qui rend toute l’équipe sourde aux notifications après quelques semaines.

Étape 16 — Surveiller un certificat SSL avant expiration

Chaque monitor HTTPS d’Uptime Kuma calcule automatiquement la date d’expiration du certificat TLS et déclenche une alerte 14 jours puis 7 jours avant échéance. Ce délai est paramétrable dans Settings → General → Notification before certificate expiration. Pour une PME qui gère cinq à dix domaines, ce garde-fou évite l’incident classique du certificat expiré un dimanche matin qui coupe l’accès aux clients toute la matinée. Combinez avec Caddy ou certbot configurés en renouvellement automatique : la double protection est gratuite et la tranquillité d’esprit qu’elle apporte n’a pas de prix.

Étape 17 — Limiter l’accès admin par IP allowlist

Uptime Kuma n’inclut pas nativement de filtrage IP. Ajoutez-le côté Caddy avec une directive @allowed qui n’autorise que vos IP fixes ou un VPN d’équipe : @allowed remote_ip 102.x.x.x 41.y.y.y, puis handle @allowed { reverse_proxy 127.0.0.1:3001 } et un handle { respond 403 } en fallback. La status page publique reste accessible via un sous-domaine séparé sans cette restriction, alors que l’admin n’est joignable que depuis le réseau autorisé. Cette séparation surface publique vs admin restreint considérablement la surface d’attaque.

Étape 18 — Mesurer l’uptime mensuel pour les rapports clients

Dans la vue d’un monitor, Uptime Kuma affiche les pourcentages d’uptime sur 24 heures, 7 jours, 30 jours et 365 jours. Ces métriques alimentent directement les rapports SLA mensuels. Pour exporter ces chiffres vers un PDF client, utilisez l’API REST d’Uptime Kuma (token généré dans Settings → API Keys), récupérez les statistiques avec une requête authentifiée, puis générez un rapport via un script Python ou un template WeasyPrint. Vos clients reçoivent en début de mois un PDF professionnel attestant du respect du SLA contractuel — argument commercial fort pour les contrats récurrents en Afrique de l’Ouest.

Étape 19 — Plan de reprise après sinistre

Si votre VPS principal est perdu, restaurer Uptime Kuma prend dix minutes : provisionnez un nouveau VPS, installez Docker et Caddy, restaurez le volume data/ depuis la dernière sauvegarde, relancez docker compose up -d. Documentez ce runbook dans un fichier partagé du dépôt Git de l’équipe. Tester ce plan une fois par trimestre transforme une promesse théorique en compétence opérationnelle.