Como Criar uma Página de Status: Componentes, Incidentes e Verificações de Disponibilidade

Uma página de status diz aos seus usuários, em um único lugar, se o serviço está funcionando. Para criar uma, você precisa de uma lista de componentes (site, API, pagamentos, envio de e-mails), o status atual de cada um, incidentes com atualizações datadas, um histórico de incidentes passados e, opcionalmente, assinaturas para que as pessoas fiquem sabendo dos problemas sem precisar verificar. A página em si é simples. A decisão importante é onde ela roda: uma página de status precisa continuar no ar quando seu app estiver fora do ar, então não deve compartilhar hospedagem, banco de dados ou pipeline de deploy com o que ela reporta.

Para que serve uma página de status

Quando algo quebra, os usuários querem saber três coisas: se o problema é só com eles, se você já sabe do problema e quando ele será resolvido. Uma página de status responde às três sem gerar uma enxurrada de chamados de suporte. Ela também constrói confiança ao longo do tempo, porque um histórico visível de incidentes com relatos honestos mostra como você lida com os problemas.

Ela não é um changelog. Novidades vão em uma página de changelog; quedas e manutenções ficam aqui.

O que a página precisa ter

Dados

Os status dos componentes costumam seguir uma lista curta e fixa: Operacional, Desempenho degradado, Queda parcial, Queda total, Em manutenção.

Páginas

• Página pública de status: um banner geral (“Todos os sistemas operacionais” ou o pior status atual), cada componente com seu status, qualquer incidente ativo com as atualizações, manutenções previstas e uma faixa com o histórico dos últimos 90 dias, se você tiver dados de verificação.
• Página do incidente: linha do tempo completa das atualizações de um incidente, com URL própria para que o suporte possa compartilhar.
• Histórico: incidentes passados, por mês.
• Assinar: cadastro por e-mail com confirmação e preferências por componente.
• Administração: criar um incidente, publicar atualizações, mudar o status dos componentes e agendar manutenções.

Permissões

O público vê tudo o que for publicado. Só a sua equipe pode publicar. Se possível, mantenha o login da administração separado do sistema de login do seu app principal, para que uma queda do seu provedor de autenticação não te deixe do lado de fora da sua própria página de status.

A decisão principal: mantenha a página independente

É aqui que a maioria das páginas de status caseiras falha. Se a sua página de status:

• roda no mesmo servidor ou na mesma conta de hospedagem do seu app,
• lê do mesmo banco de dados,
• fica atrás da mesma configuração de domínio ou CDN,
• ou é publicada pelo mesmo pipeline,

então muitas quedas também vão derrubá-la, justamente quando as pessoas mais precisam dela. Passos práticos:

• Hospedagem separada. Um projeto ou provedor diferente do app principal.
• Subdomínio próprio, como status.exemplo.com, apontado separadamente no DNS. Veja como funcionam domínios e DNS.
• Dados próprios. Os incidentes ficam no armazenamento da própria página de status, e não no banco de dados do app.
• Uma versão estática de reserva. Algumas equipes deixam a página pública estática e a reconstroem a cada atualização, para que quase nada possa quebrar.

Atualização manual ou verificações automáticas

Manual (comece por aqui)

Sua equipe publica incidentes e muda o status dos componentes manualmente, pela página de administração. É assim que muitas páginas de status funcionam na prática, porque um julgamento humano (“pagamentos estão lentos para alguns tipos de cartão”) é mais útil do que um ponto vermelho automático.

Para descobrir rapidamente quando há problemas, use um monitor de uptime externo que verifique seu app a cada minuto, mais ou menos, e avise por e-mail, SMS ou chat. Muitos serviços de monitoramento têm planos gratuitos.

Automatizado

Automatizar significa que algo verifica cada componente regularmente e atualiza o status. Isso exige um código que rode em agenda, a partir de fora da infraestrutura do seu app principal. Dois padrões comuns:

• Um monitor externo chama sua página de status por meio de um webhook quando uma verificação falha ou se recupera, e a página atualiza o componente.
• Um job agendado na hospedagem da própria página de status faz ping em cada componente e registra o resultado. Confira como sua hospedagem lida com tarefas agendadas antes de depender disso; nosso guia sobre como rodar jobs em segundo plano explica as opções.

Mudanças automáticas podem oscilar (no ar, fora, no ar) em uma rede lenta. Exija duas ou três falhas seguidas antes de mudar um status, e deixe uma pessoa confirmar antes de anunciar uma queda grave.

Como escrever atualizações de incidente

• Publique cedo. “Estamos investigando relatos de falha no login” em poucos minutos vale mais do que uma mensagem perfeita uma hora depois.
• Diga o que os usuários percebem, e não o que quebrou internamente.
• Prometa o horário da próxima atualização e cumpra.
• Feche com um resumo curto quando resolver: o que aconteceu, por quanto tempo, o que você vai mudar.

Um primeiro prompt que funciona

Crie uma página de status independente para nosso app Parcelio, hospedada separadamente em status.parcelio.com. Componentes: Site, API de rastreamento, Notificações, Pagamentos, cada um com status Operacional, Desempenho degradado, Queda parcial, Queda total ou Em manutenção. A página pública mostra um banner geral com o pior status atual, cada componente com seu status, incidentes ativos com atualizações datadas da mais nova para a mais antiga, manutenções previstas e uma lista de incidentes passados por mês. Cada incidente tem sua própria página. Adicione uma página de administração protegida por senha para criar incidentes (título, impacto, componentes afetados), publicar atualizações (mensagem e status: Investigando, Identificado, Monitorando, Resolvido), mudar o status dos componentes e agendar manutenções. Adicione um endpoint POST /api/check-result que aceite o nome de um componente e up/down de um monitor externo, protegido por um token secreto, e marque um componente como Desempenho degradado somente após três falhas consecutivas. Guarde tudo no banco de dados deste próprio app. Design simples e calmo que carregue rápido em celulares.

Etapas de criação

1. Página pública e administração com incidentes manuais. Só isso já é uma página de status que funciona.
2. Hospede-a separadamente e aponte um subdomínio para ela.
3. Páginas de incidente e histórico.
4. Janelas de manutenção.
5. Assinaturas. Cadastro por e-mail com confirmação dupla e notificações a cada novo incidente ou atualização. O e-mail precisa de um provedor; veja como enviar e-mails pelo seu app.
6. Webhook de monitor, se você quiser mudanças automáticas de status.
7. Faça um simulado. Crie um incidente falso, publique atualizações, resolva, confira os e-mails e depois apague.

Erros comuns

• Hospedar junto com o app. O erro mais comum e o mais grave.
• Uma página que sempre diz “Todos os sistemas operacionais”. Se ela nunca mostra problemas, os usuários deixam de confiar nela.
• Sem data, hora ou fuso horário. Sempre mostre os horários com o fuso.
• Depender do login do app principal para a página de administração.
• Silêncio entre as atualizações. “Sem novidades, ainda trabalhando nisso” é uma atualização válida.
• Status automáticos oscilando. Exija falhas repetidas antes de mudar.

Quando um serviço de página de status pronto é a melhor escolha

Serviços de página de status prontos são feitos para resolver o problema da independência: rodam em infraestrutura separada, cuidam das notificações de assinantes por e-mail e SMS e costumam incluir monitoramento e integrações com ferramentas de incidentes. Se a disponibilidade faz parte do que seus clientes pagam, ou se você tem obrigações contratuais de reportar incidentes, um serviço dedicado geralmente vale a pena. Muitos têm planos gratuitos ou de baixo custo para equipes pequenas, então confira antes de construir.

Crie a sua quando quiser controle total de design e de texto, quando suas necessidades forem simples (poucos componentes, atualizações manuais) ou quando a página de status fizer parte de um produto que você está criando para outras pessoas.

Criando com a Mythex

Na Mythex você pode criar a página de status como um projeto próprio, separado do app principal, o que dá hospedagem separada e banco de dados próprio. Descreva no chat, confira no preview ao vivo, depois publique e conecte um subdomínio como status.seudominio.com (domínios personalizados estão no plano Pro). Lembre que os apps e bancos de dados publicados na Mythex entram em modo de espera quando ficam ociosos e voltam no próximo acesso, então o primeiro carregamento depois de um período parado pode ser mais lento; uma página simples e leve ajuda.

A Mythex não documenta jobs agendados, então para verificações automáticas use um monitor de uptime externo que chame um endpoint de webhook na sua página de status (veja a receita de webhooks). Os e-mails de alerta para assinantes passam pelo seu próprio provedor, com a chave guardada como segredo do projeto (receita de envio de e-mail).

Perguntas