Ce guide passe en revue les choix à faire pour la page de statut d’un SaaS : quoi y afficher, quand un moniteur de disponibilité doit déclarer une panne, comment rédiger les mises à jour d’incident et où héberger la page. L’exemple concret, ce sont la page de statut et les moniteurs de disponibilité que je viens d’ajouter à Kookee, et les captures d’écran viennent de Lumen, le produit d’analytique fictif de mon projet de démo. L’un de ces moniteurs a été mis à l’épreuve plus tôt que prévu : en prenant les captures, j’ai désactivé par erreur le portail du projet de démo, et ses deux moniteurs l’ont détecté 68 et 78 secondes plus tard.
Ce qu’on met sur une page de statut
Une page de statut utile a quatre parties :
les éléments de votre produit, chacun avec son statut actuel ;
les incidents en cours, avec ce que vous savez jusqu’ici ;
la maintenance que vous avez prévue, avant qu’elle commence ;
le passé récent : les incidents des derniers mois, et la part de ce temps pendant laquelle chaque élément fonctionnait.
Au-dessus, une ligne résume toute la page : un visiteur qui veut seulement savoir si le problème vient de chez lui peut s’arrêter là. La page de Kookee affiche « Tous les systèmes sont opérationnels », « Perturbation mineure du service », « Panne majeure » ou « Maintenance en cours », selon les composants et les incidents ouverts.
Nommez les composants comme vos clients les nomment
Un composant, c’est quelque chose qu’un client peut confronter à ce qu’il voit. Lumen liste Dashboards, Data ingestion, Public API, Email reports et Help center. Il ne liste ni ses workers de file d’attente ni sa base de données, parce que personne hors de l’équipe ne sait à quoi ils servent. Sur la capture ci-dessus, l’incident fictif de Lumen indique Email reports comme composant touché, et plus bas sur la page, ce composant affiche « Performances dégradées ». Un client qui n’a pas reçu un rapport programmé peut faire le lien avec ce qu’il constate.
Kookee autorise 10 composants avec le forfait Free et 50 avec Pro. Chacun a une barre par jour, colorée selon le pire statut qu’il a eu ce jour-là : 90 jours sur un grand écran, les 30 derniers sur un téléphone, et aucune si vous désactivez Afficher la disponibilité.
Décidez quand un site est vraiment en panne
Un moniteur de disponibilité interroge une URL à intervalle régulier et doit décider quand un échec devient une panne. Chez Kookee, la règle est de trois vérifications échouées d’affilée. Après un échec, le moniteur vérifie à nouveau 20 secondes plus tard : les trois échecs prennent donc environ 40 secondes quel que soit l’intervalle, plus si chaque vérification attend jusqu’à son délai d’expiration. L’intervalle décide seulement quand arrive le premier échec : sur Pro et Ultra, un moniteur peut vérifier toutes les minutes, sur Free toutes les cinq minutes au mieux. Un seul échec ne déclenche rien, et deux vérifications réussies d’affilée font repasser le moniteur en ligne.
Voici ce que cela a donné quand j’ai désactivé le portail de démo. Le portail s’est arrêté à 08:02:36 UTC. Les moniteurs l’ont déclaré en panne à 08:03:44 et 08:03:54, chacun après trois 404, et celui du centre d’aide a ouvert un incident en brouillon, « Help center is down ». Le portail était de retour à 08:04:18, les moniteurs sont repassés en ligne à 08:05:24 et 08:05:34, et le brouillon s’est résolu tout seul sans jamais atteindre la page publique. La panne enregistrée par chaque moniteur a duré à peu près autant que la vraie, avec environ une minute de retard au début comme à la fin : c’est le prix de la confirmation avant de déclarer une panne.
Quelques règles de plus décident si vous pouvez faire confiance au moniteur. Un moniteur qui n’a jamais réussi une vérification se contente d’alerter votre équipe : une faute de frappe dans l’URL ne doit pas montrer à vos clients une panne qui n’a jamais eu lieu. Une fois qu’il a été en ligne, un moniteur en panne passe son composant en « Panne majeure », quel que soit le reste de sa configuration : la page ne peut donc pas afficher « Opérationnel » pendant que la vérification échoue. Et si le composant est en maintenance planifiée, le moniteur attend la fin de la fenêtre pour déclarer la panne.
La suite, vous la choisissez pour chaque moniteur : Alerte uniquement, Ouvrir un incident en brouillon ou Publier un incident immédiatement. Un brouillon vous donne un incident prêt, à vérifier et à reformuler avant sa diffusion. La publication immédiate convient à une URL dont l’échec signifie toujours que des clients sont touchés, comme le health check de votre API.
Rédigez des mises à jour exploitables
Un incident, c’est un titre et une suite de mises à jour. Chaque mise à jour a un statut, et pour les incidents, Kookee s’en tient à quatre : « Analyse en cours », « Cause identifiée », « Sous surveillance » et « Résolu ». Le titre doit nommer ce que les clients remarquent (« Les tableaux de bord se chargeaient lentement »), pas la cause.
Chaque mise à jour doit répondre à la question suivante du client. Dans l’incident résolu de Lumen ci-dessous, la première mise à jour dit ce qui est touché, avec un chiffre : « Certains tableaux de bord mettent plus de 20 secondes à se charger. » « Cause identifiée » donne la cause dès qu’elle est connue : « La mise en production de ce matin a changé la façon dont les grands graphiques d’entonnoir sont interrogés. » « Sous surveillance » dit ce que l’équipe surveille avant de déclarer le problème réglé : « Nous surveillons les temps de chargement pendant l’heure qui vient. » L’incident sur les rapports par e-mail, plus haut, répond à l’autre question des clients, à savoir si quelque chose est perdu : « Les rapports en retard seront bien envoyés, et aucun n’est perdu. »
Dans Kookee, chaque mise à jour fixe aussi le statut de chaque composant concerné : une seule mise à jour change à la fois l’incident et la liste des composants.
Annoncez la maintenance avant qu’elle commence
Dans Kookee, une fenêtre de maintenance est publique dès que vous la planifiez, sous « Maintenances à venir ». Elle est en cours entre son début et sa fin, et ses composants affichent « En maintenance ». Ensuite, elle est terminée, sans que personne ait à la lancer ou à l’arrêter à la main. Dites ce que les clients risquent de remarquer et pendant combien de temps, comme le fait la mise à niveau de base de données de Lumen : « Pendant la fenêtre de maintenance, les tableaux de bord et l’API peuvent répondre lentement, 15 minutes au plus. »
Comment Kookee calcule la disponibilité
Kookee ne compte comme indisponibilité que le temps passé en « Panne majeure ». Les performances dégradées et les pannes partielles colorent la barre du jour, mais ne font pas baisser le chiffre. Le pourcentage couvre 90 jours et commence à l’ajout du composant : les jours d’avant sont gris, pas verts. Il est arrondi vers le bas : 99,996 % s’affiche 99,99 %, jamais 100,00 %.
Hébergez-la loin de ce qu’elle surveille
Une page de statut servie par le système qu’elle décrit tombe en panne avec lui. La page hébergée de Kookee se trouve à <your-project>.kookee.dev/status, à l’écart de vos propres serveurs. Si vous la voulez sur votre propre domaine, la même page se construit avec @kookee/react/status : StatusHeadline et StatusOverview pour la page, StatusIncidentArticle pour chaque incident. Servez-la depuis un autre endroit que l’application qu’elle surveille, par exemple un hébergeur statique, et laissez le navigateur lire le statut depuis l’API de Kookee :
import { useStatus } from '@kookee/react';
import { StatusHeadline, StatusOverview } from '@kookee/react/status';
const { data: status } = useStatus({ refreshSeconds: 60 });
if (!status) return null;
<StatusHeadline status={status} />
<StatusOverview status={status} incidentHref="/status/incidents/{id}" />Les lectures du statut ne comptent pas dans vos requêtes API mensuelles. Dans chacun des quatre starters de Kookee, KOOKEE_STATUS=true ajoute /status et une page par incident. La même limite s’applique à Kookee lui-même : la page et les composants lisent l’API de Kookee, donc si cette API est en panne, ils ne peuvent pas se charger non plus.
Configurez-la dans Kookee
Ouvrez Page de statut, allez dans l’onglet Composants et cliquez sur Ajouter un composant pour chaque élément que vos clients voient.
Ouvrez Surveillance de disponibilité, cliquez sur Ajouter un moniteur, saisissez l’URL, choisissez un Intervalle de vérification et un Composant, puis le comportement En cas de panne.
Ouvrez Portail public, activez l’option Activer le portail public si elle est désactivée, et cochez Page de statut sous Modules du portail.
De retour sur Page de statut, cliquez sur Voir la page de statut.
Configurer une page de statut couvre les incidents et la maintenance, et Surveiller votre site avec des vérifications de disponibilité tous les réglages des moniteurs.
Ce que la page de statut de Kookee ne fait pas encore
Les visiteurs ne peuvent pas s’abonner aux mises à jour par e-mail ou RSS. Il n’y a ni alertes SMS ni plannings d’astreinte, les moniteurs ne font que des vérifications HTTP et HTTPS, et il n’existe pas de pages de statut privées. La page hébergée ne peut pas avoir son propre domaine ; pour la mettre sur le vôtre, passez par les composants React.
FAQ
La page de statut est-elle gratuite ? Oui. Tous les forfaits incluent la page de statut et les moniteurs de disponibilité. Free compte 10 composants et 3 moniteurs, vérifiés toutes les 5 minutes au mieux ; Pro compte 50 composants et 20 moniteurs, vérifiés jusqu’à une fois par minute.
Qui est prévenu quand un moniteur tombe en panne ? Les propriétaires et les administrateurs du projet, dans Kookee et par e-mail. Les webhooks peuvent recevoir un événement monitor.down, et sur Pro et Ultra, les intégrations Slack, Discord et Telegram peuvent le publier dans le canal de votre équipe.
Un assistant IA peut-il publier des incidents ? Oui. Via le serveur MCP de Kookee, un assistant avec un accès en écriture peut lire le statut, et créer, mettre à jour et résoudre des incidents.
Pour aller plus loin
Configurer une page de statut : chaque étape dans Kookee, des composants à la maintenance.
Afficher votre page de statut sur votre propre site : les composants React, l’API et les starters.
Vos webhooks ne devraient pas faire confiance à l’URL qu’on leur donne : pourquoi un serveur qui appelle les URL de ses clients doit vérifier où elles pointent.