Una página de estado que no es una suscripción de US$29/mes

Una página de estado es una de esas cosas que casi por reflejo se compra como suscripción SaaS, porque históricamente significaba correr todo un servicio de monitoreo separado solo para responder “¿está caído para todos o solo para mí?”. La versión de Railyard existe porque la plataforma ya corre comprobaciones de disponibilidad en cada app que hospeda —la página de estado es una vista sobre datos que ya existen, no un sistema nuevo que montar.

Qué muestra realmente

Crea una desde Status pages en la barra lateral (solo admins): un título, una dirección (https://app.railyard.run/status/<address>), y qué apps incluir, cada una con su propio nombre de cara al público —los clientes ven “API” y “Panel”, nunca los slugs internos de tus apps.

Los visitantes obtienen:

• Un banner general —operativo, degradado, caída parcial o caída mayor, resumido entre todas las apps de la página.
• Una fila por app con su estado en vivo: operativo, degradado (2 o más de las últimas 5 comprobaciones fallaron), caído, en mantenimiento o dormido.
• 90 días de barras de disponibilidad diaria y el porcentaje, construidos con las mismas comprobaciones que Railyard ya corre —no un servicio de ping separado con su propia tasa de falsos positivos que ajustar.
• Incidentes actuales y recientes, los últimos 14 días.

La página se refresca cada minuto y respeta la preferencia de modo claro/oscuro del visitante. Un endpoint /status/<address>.json da los mismos datos —estado, disponibilidad de 90 días, incidentes abiertos— para lo que quieras construir encima por tu cuenta.

Incidentes que no necesitan que alguien se acuerde de cerrarlos

Este es el detalle que importa más que las barras de disponibilidad: los incidentes se abren y se resuelven solos, ligados a las mismas comprobaciones —cuando una app se cae, se abre un incidente; cuando vuelve, el incidente lo refleja sin que una persona tenga que entrar a actualizar un campo de estado a mano. Igual puedes publicar tus propios incidentes a mano (título, nivel de impacto, un estado, una primera actualización que ven los visitantes, y más actualizaciones a medida que cambian las cosas), lo cual importa para los casos que la automatización no puede saber —una dependencia de terceros degradada, una ventana de mantenimiento planificada— pero el caso base de “se cayó y volvió” no necesita intervención manual alguna.

Lo que honestamente todavía no hace

Dos límites reales, dichos con claridad en vez de descubiertos después: la página vive en la dirección propia de Railyard, todavía no se puede servir en tu propio dominio. Y sus datos vienen enteramente de comprobaciones de disponibilidad contra las direcciones web de tus apps —una app que solo tiene worker, sin nada escuchando en un puerto, no tiene nada que comprobar, así que no tiene una fila con sentido en una página de estado.

Por qué esto es algo más chico de lo que parece

La ingeniería real detrás de una página de estado —historial de disponibilidad, máquinas de estado de incidentes, una vista pública de solo lectura— ya tiene que existir para que funcionen el monitoreo y las alertas propios de la plataforma. Un SaaS dedicado a páginas de estado vende acceso a datos que un PaaS ya recolecta sobre tus apps; aquí, la página es simplemente esos datos hechos públicos a propósito.

Referencia completa: Páginas de estado.