Uma status page que não é uma assinatura de US$29/mês
Uma status page é uma daquelas coisas que se compra como assinatura SaaS quase por reflexo, porque historicamente significava rodar todo um serviço de monitoramento separado só para responder “está fora do ar para todo mundo ou só para mim.” A versão do Railyard existe porque a plataforma já roda verificações de uptime em cada app que hospeda — a status page é uma visão sobre dados que já existem, não um sistema novo para montar.
O que ela de fato mostra
Crie uma em Status pages no menu lateral (só admins): um título, um endereço (https://app.railyard.run/status/<address>), e quais apps incluir, cada um com seu próprio nome voltado ao público — os clientes veem “API” e “Dashboard”, nunca os slugs internos do seu app.
Os visitantes recebem:
- Um banner geral — operacional, degradado, queda parcial ou queda maior, agregado entre todos os apps da página.
- Uma linha por app com o estado em tempo real: operacional, degradado (2 ou mais das últimas 5 verificações falharam), fora do ar, em manutenção, ou dormindo.
- Barras de uptime diário de 90 dias e a porcentagem, construídas a partir das mesmas verificações que o Railyard já roda — não um serviço de ping separado com sua própria taxa de falso positivo para ajustar.
- Incidentes atuais e recentes, dos últimos 14 dias.
A página atualiza a cada minuto e segue a preferência de tema claro/escuro do próprio visitante. Um endpoint /status/<address>.json dá o mesmo dado — estado, uptime de 90 dias, incidentes abertos — para qualquer coisa que você queira construir em cima por conta própria.
Incidentes que não exigem que alguém lembre de fechá-los
Esse é o detalhe que importa mais do que as barras de uptime: incidentes abrem e se resolvem por conta própria, atrelados às mesmas verificações — quando um app cai, um incidente abre; quando ele volta, o incidente reflete isso sem um humano precisar entrar e atualizar um campo de status. Você ainda pode postar seus próprios incidentes à mão (título, nível de impacto, um status, uma primeira atualização que os visitantes veem, e atualizações seguintes conforme as coisas mudam), o que importa para os casos que a automação não tem como saber — uma dependência de terceiros degradada, uma janela de manutenção planejada — mas o caso básico de “caiu e voltou” não exige nenhuma intervenção manual.
O que ela é honesta sobre ainda não fazer
Dois limites reais, declarados claramente em vez de descobertos depois: a página vive no próprio endereço do Railyard, ainda não pode ser servida no seu próprio domínio. E os dados dela vêm inteiramente de verificações de uptime contra os endereços web dos seus apps — um app só de worker, sem nada escutando numa porta, não tem nada para verificar, então não tem uma linha significativa numa status page.
Por que isso é uma coisa menor do que parece
A engenharia real por trás de uma status page — histórico de uptime, máquinas de estado de incidente, uma visão pública de leitura — já precisa existir para o próprio monitoramento e alertas da plataforma funcionarem. Um SaaS dedicado de status page está vendendo acesso a dados que um PaaS já coleta sobre seus apps; aqui, a página é só esse dado tornado público de propósito.
Referência completa: Status pages.