Une page de statut qui n'est pas un abonnement à 29 $/mois

Une page de statut est une de ces choses qu’on achète presque par réflexe comme abonnement SaaS, parce qu’historiquement ça voulait dire faire tourner tout un service de surveillance séparé juste pour répondre à « est-ce down pour tout le monde ou juste pour moi ». La version de Railyard existe parce que la plateforme fait déjà tourner des vérifications de disponibilité sur chaque application qu’elle héberge — la page de statut est une vue sur des données qui existent déjà, pas un nouveau système à mettre en place.

Ce qu’elle montre vraiment

Créez-en une depuis Status pages dans la barre latérale (admins seulement) : un titre, une adresse (https://app.railyard.run/status/<address>), et quelles applications inclure, chacune avec son propre nom public — les clients voient « API » et « Dashboard », jamais vos slugs d’application internes.

Les visiteurs obtiennent :

• Une bannière générale — opérationnel, dégradé, panne partielle, ou panne majeure, agrégée sur toutes les applications de la page.
• Une ligne par application avec son état en direct : opérationnel, dégradé (2 des 5 dernières vérifications ou plus ont échoué), down, en maintenance, ou endormie.
• 90 jours de barres de disponibilité quotidiennes et le pourcentage, construits à partir des mêmes vérifications que Railyard fait déjà tourner — pas un service de ping séparé avec son propre taux de faux positifs à régler.
• Les incidents actuels et récents, les 14 derniers jours.

La page se rafraîchit chaque minute et suit la préférence clair/sombre propre au visiteur. Un point de terminaison /status/<address>.json donne les mêmes données — état, disponibilité sur 90 jours, incidents ouverts — pour tout ce que vous voulez construire par-dessus vous-même.

Des incidents qui n’ont pas besoin que quelqu’un se souvienne de les fermer

C’est le détail qui compte plus que les barres de disponibilité : les incidents s’ouvrent et se résolvent tout seuls, liés aux mêmes vérifications — quand une application tombe, un incident s’ouvre; quand elle revient, l’incident le reflète sans qu’un humain doive se connecter pour mettre à jour un statut. Vous pouvez toujours publier vos propres incidents à la main (titre, niveau d’impact, un statut, une première mise à jour que les visiteurs voient, et d’autres mises à jour au fil du temps), ce qui compte pour les cas que l’automatisation ne peut pas connaître — une dépendance tierce dégradée, une fenêtre de maintenance planifiée — mais le cas de base « c’est tombé et c’est revenu » n’a besoin d’aucune intervention manuelle.

Ce qu’elle ne fait pas encore, dit honnêtement

Deux vraies limites, dites clairement plutôt que découvertes plus tard : la page vit sur la propre adresse de Railyard, elle ne peut pas encore être servie sur votre propre domaine. Et ses données viennent entièrement des vérifications de disponibilité des adresses web de vos applications — une application uniquement worker, sans rien qui écoute sur un port, n’a rien à vérifier, donc aucune ligne significative sur une page de statut.

Pourquoi c’est une plus petite chose qu’il n’y paraît

Le véritable travail d’ingénierie derrière une page de statut — historique de disponibilité, machine à états des incidents, une vue publique en lecture seule — doit déjà exister pour que la propre surveillance et les alertes de la plateforme fonctionnent. Un SaaS de page de statut dédié vend l’accès à des données qu’une PaaS collecte déjà sur vos applications; ici, la page n’est que ces données rendues publiques exprès.

Référence complète : Pages de statut.