Créer une page de statut publique sans Statuspage.io : auto-hébergée, en 30 minutes, sur un autre serveur que votre produit

Pendant une panne, les clients font trois choses : ils rechargent la page, ils écrivent au support, et ils cherchent une page de statut. S'il n'y en a pas, ou si elle est tombée avec le reste, votre charge de support double au moment où vous avez besoin de vos mains pour réparer. Statuspage.io et consorts résolvent cela pour 29 à 99 dollars par mois avec vos données clients aux États-Unis. Voici la version sur votre propre VPS, avec les mêmes fonctions, pour le prix du plus petit serveur chez votre hébergeur.

La règle qui décide de tout

La page de statut ne tourne pas sur l'infrastructure qu'elle surveille. Autre hébergeur, ou au moins autre datacenter, autre fournisseur DNS si possible, certificat propre. Une page de statut qui affiche « tout va bien » parce qu'elle est elle-même hors ligne est pire que pas de page du tout.

En pratique : un VPS 1 vCPU / 1 Go RAM chez un second hébergeur (Hetzner si vous êtes chez OVH, ou l'inverse) coûte 4 à 5 euros par mois et fait tourner cela sans peine.

Étape 1 : installer Uptime Kuma

Uptime Kuma est open source (MIT), a des contrôles HTTP/TCP/DNS/ping/mot-clé, des pages de statut publiques, des messages d'incident et des notifications vers ntfy, e-mail et environ quatre-vingt-dix autres canaux. Un conteneur :

# Sur le VPS de statut
sudo apt install -y docker.io docker-compose-v2 caddy
sudo install -d /opt/status && cd /opt/status
sudo tee docker-compose.yml >/dev/null <<'EOF'
services:
  kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports: ["127.0.0.1:3001:3001"]
    volumes:
      - ./data:/app/data
    logging:
      driver: json-file
      options: { max-size: "10m", max-file: "3" }
EOF
sudo docker compose up -d

Ouvrez http://<ip-vps>:3001 via un tunnel SSH (ssh -L 3001:127.0.0.1:3001 status-vps) et créez le compte admin. Faites-le maintenant : le premier visiteur d'une installation fraîche choisit le compte admin.

Étape 2 : rendre public avec domaine et TLS propres

# DNS : status.example.be → enregistrement A vers le VPS de statut, TTL 300 (pas 86400 !)
sudo tee /etc/caddy/Caddyfile >/dev/null <<'EOF'
status.example.be {
    reverse_proxy 127.0.0.1:3001
    header {
        # Pas de mise en cache de la page de statut par des proxys/CDN intermédiaires
        Cache-Control "no-store"
        X-Frame-Options "SAMEORIGIN"
    }
    encode gzip
}
EOF
sudo systemctl reload caddy
curl -sI https://status.example.be | head -3      # 200, certificat Let's Encrypt

Caddy s'occupe du certificat. Deux détails qui comptent pendant une panne :

• TTL DNS de 300 secondes. Si vous devez un jour remplacer le VPS de statut, vous voulez pouvoir repointer l'enregistrement A en cinq minutes, pas en un jour.
• Cache-Control: no-store. Un CDN ou un proxy d'entreprise qui met en cache la page de ce matin affiche « operational » alors que votre incident dure depuis deux heures.

Étape 3 : les contrôles — de l'extérieur, sur ce que le client voit

Dans l'interface Kuma, Add New Monitor. Un contrôle par service qui fait ce que fait un visiteur :

Service	Type	Réglage
Site web / application	HTTP(s) – Keyword	URL de la page de connexion, mot-clé Connexion (pas seulement le statut 200 : une page d'erreur renvoie aussi 200)
API	HTTP(s) – Json Query	https://api.example.be/healthz, requête $.status == "ok"
Mail	TCP Port	mail.example.be:587 et :993
DNS	DNS	votre propre domaine contre votre propre serveur de noms, enregistrement attendu
TLS	(inclus dans le contrôle HTTP)	Certificate Expiry Notification activé, 14 jours

Intervalle 60 s, retries 2 (donc down après 3 tentatives échouées = ~3 minutes ; protection contre le battement), Upside Down Mode désactivé. Réglez les Accepted Status Codes du contrôle sur 200-299 — pas 200-399, sinon une redirection vers une page d'erreur compte comme up.

Pour les services derrière un pare-feu, joignables uniquement en interne, utilisez un moniteur Push : l'hôte interne se signale chaque minute par un curl vers Kuma, et Kuma alerte si le push s'arrête. Kuma reste hors de votre réseau et vous voyez quand même les services internes.

# Sur l'hôte interne, cron chaque minute :
* * * * * curl -fsS -m 10 "https://status.example.be/api/push/AbCdEf1234?status=up&msg=OK" >/dev/null

Étape 4 : la page publique

Status Pages → New Status Page : slug main, titre, et glissez les moniteurs dans des groupes (« Site web », « API », « E-mail »). Ce que vous ne mettez pas sur la page publique :

• Les URL et ports de vos contrôles (Kuma ne les affiche pas, sauf si vous donnez au moniteur un nom qui est une URL — appelez-le « Portail client », pas « https://app.example.be/login »).
• Les services internes (base de données, Redis, sauvegarde). Le client n'y gagne rien et c'est de l'information pour un attaquant.
• Les graphiques de temps de réponse si vous ne voulez pas les expliquer ; « Show Certificate Expiry » est acceptable — c'est un signe de rigueur.

Réglez Custom domain sur status.example.be et une courte Description avec ce que le client doit faire en cas de panne (« Pour les questions urgentes : support@example.be — n'utilisez pas la messagerie de la plateforme pendant une panne »).

Étape 5 : les incidents — depuis votre téléphone

Une page de statut sans messages d'incident n'affiche que du rouge et du vert. Ce qu'un client veut lire : quoi, qui y travaille et quand arrive la prochaine mise à jour. Dans Kuma : sur la page de statut, Create Incident, titre, texte, style (info/warning/danger). Cela fonctionne depuis le navigateur mobile.

Gardez le format fixe, une mise à jour prend alors 30 secondes :

[14:05] Investigation — L'API répond lentement depuis 13:50. Nous recherchons la cause. Prochaine mise à jour à 14:30.
[14:28] Identifié — Cause : disque plein sur le serveur de base de données. Nettoyage en cours. Prochaine mise à jour à 15:00.
[14:52] Résolu — Espace disque rétabli à 14:45 ; temps de réponse de l'API normaux depuis 14:47. Post-mortem sous 2 jours ouvrés.

Ne conservez pas les incidents uniquement sur la page. Copiez la chronologie dans votre registre des incidents après coup — c'est la pièce de preuve NIS2 n° 12, et le compte à rebours « alerte précoce sous 24 heures » commence à la première ligne.

Étape 6 : notifications et le heartbeat de la page de statut elle-même

Settings → Notifications → ntfy : topic status, et rattachez-le à tous les moniteurs (Apply on all existing monitors). Vous recevez ainsi le message avant que le client ne le voie. Voir astreinte sans PagerDuty pour l'escalade.

Et surveillez le surveillant : un moniteur à un autre endroit (votre serveur principal, ou l'offre gratuite d'un service externe) qui contrôle https://status.example.be toutes les 5 minutes. Kuma ne peut pas se signaler lui-même s'il est hors ligne.

# Sur votre serveur principal (qui N'EST PAS le VPS de statut) : cron toutes les 5 min
*/5 * * * * curl -fsS -m 10 -o /dev/null https://status.example.be || curl -s -H "Title: STATUS PAGE DOWN" -H "Priority: urgent" -d "status.example.be unreachable" https://ntfy.example.be/oncall

Maintenance

# Sauvegarde des données Kuma (SQLite + config) : quotidienne, vers un autre endroit
0 4 * * * root tar -C /opt/status -czf /var/backups/kuma-$(date +\%F).tgz data && find /var/backups -name 'kuma-*.tgz' -mtime +14 -delete
# Mises à jour : Kuma via le tag d'image ; le VPS via unattended-upgrades
cd /opt/status && sudo docker compose pull && sudo docker compose up -d

Pièges

• Page de statut sur le même serveur. Encore une fois, parce que c'est l'erreur que tout le monde commet une fois. « Une autre VM chez le même hébergeur dans le même rack » compte aussi comme le même serveur quand l'hébergeur a une panne réseau.
• Ne vérifier que HTTP 200. Une page de maintenance, un blocage WAF et une application vide renvoient tous les trois 200. Les contrôles par mot-clé ou JSON regardent le contenu.
• Un intervalle trop agressif. 20 s avec 0 retry donne une page qui clignote en rouge à chaque hoquet réseau. 60 s avec 2 retries est le bon compromis pour une page publique ; votre supervision interne peut être plus fine.
• Oublier que la page est publique. Noms de moniteurs, textes d'incident et descriptions sont lisibles par tous, concurrents et attaquants compris. Pas de noms d'hôtes, pas de « le serveur de base de données 3 est plein ».
• Personne pour les mises à jour. Un incident sans mise à jour pendant 45 minutes se lit comme « ils ne savent pas ». Convenez de qui tient la page pendant un incident — pas la personne qui répare.

Ce qu'il vous manque encore

• Le lien avec la cause. Kuma voit que l'API est lente ; pourquoi (disque plein, CPU, un déploiement) est dans votre supervision serveur. Deux systèmes, deux connexions, en plein incident.
• L'accès par client. Une page publique pour tout le monde. Un MSP veut par client une page avec uniquement ses services, éventuellement derrière un mot de passe ou un token.
• La preuve. Les pourcentages d'uptime sur la page sont ce que Kuma a mesuré ; pour un rapport SLA ou un dossier NIS2, vous les voulez signés, avec les mesures brutes jointes.

Comment monsys fait

Les contrôles d'uptime de monsys tournent depuis le hub — un autre emplacement que vos serveurs — avec des contrôles HTTP, TLS et TCP, deux échecs consécutifs avant de déclarer quelque chose down, et des alertes d'expiration de certificat à 14 jours. Chaque tenant publie des pages de statut sous son propre slug, publiques, via un lien secret ou avec mot de passe — un MSP a ainsi une page par client. Un contrôle en échec est une alerte ordinaire dans le même pipeline que les métriques de l'agent, de sorte que la page de statut et la cause (disque plein sur l'hôte de base de données) sont sur le même écran. Les mesures alimentent le moteur SLA et le rapport mensuel signé.

FAQ

Quelle page de statut auto-hébergée est la plus simple ?

Uptime Kuma : un conteneur, contrôles et page de statut en un, messages d'incident intégrés, activement maintenu. Alternatives : Gatus (configuration en YAML, pas d'interface pour les incidents), Cachet (page de statut seule, contrôles à part), Statping-ng.

La page de statut doit-elle vraiment être chez un autre hébergeur ?

Oui, si vous voulez qu'elle fonctionne pendant une panne chez votre hébergeur — et c'est exactement là que vous en avez besoin. Au minimum un autre datacenter ; idéalement un autre hébergeur et un autre fournisseur DNS pour le sous-domaine de statut.

Comment mettre la page de statut sur mon propre domaine ?

Un enregistrement A status.example.be vers le VPS de statut (TTL 300), Caddy ou nginx comme reverse proxy avec certificat Let's Encrypt automatique, et dans Kuma le domaine personnalisé sur la page de statut. Ne réutilisez pas un certificat wildcard de votre domaine principal : s'il expire ou est compromis, vous voulez que la page de statut en soit indépendante.