Como é uma boa página de status pública

Uma página de status pública é o lugar para onde os clientes vão durante uma queda. Uma boa página de status reduz o número de tickets de suporte e constrói confiança. Do que ela se compõe.

O que uma boa página de status precisa ter

O estado atual de cada serviço-chave. Não apenas "tudo OK", mas dividido por componentes (API, web, dashboard, emailing, payment processing).
Histórico de incidentes dos últimos 90 dias. Sem tentar esconder nada - um histórico transparente constrói confiança.
Uma métrica de uptime (normalmente de 30 dias) para cada componente, expressa como uma percentagem transparente.
Manutenção planejada. Um banner com a data e uma descrição do que ficará indisponível.
Incidente ativo com uma linha do tempo de atualizações. Investigating → Identified → Monitoring → Resolved.
Um formulário de inscrição. Os clientes recebem um e-mail quando o status muda e não precisam verificar a página repetidamente.

Uma hierarquia de componentes clara

Em vez de um único registro "monitor", divida o serviço em componentes que façam sentido do ponto de vista do cliente:

Web App - frontend (usado pelos visitantes)
API - backend para integrações programáticas
Auth / Login - login
Email delivery - e-mails transacionais
Background jobs - sync, faturamento, exportações
Status page - componente meta: a própria página de status também pode cair (por isso ela deveria rodar em uma infraestrutura diferente da do produto)

Incident communication: anatomia de uma boa atualização

Durante uma queda real, siga estas fases:

Investigating - "Identificamos um problema com [componente]. A equipe está investigando a causa." (até 5 min após a detecção)
Identified - "A causa é [resumidamente]. Estamos trabalhando numa correção. ETA [horário]." (quando você sabe o que está causando o problema)
Monitoring - "Implantamos uma correção. Estamos observando para garantir que o problema não se repita." (após implantar a solução)
Resolved - "O incidente está resolvido. Duração X minutos. Um postmortem virá a seguir." (após recuperação confirmada)

Cada fase recebe um timestamp e a sua própria atualização. Após o incidente, publique um post-mortem (root cause, timeline e medidas que evitam a repetição).

Regra: Nunca use frases vagas do tipo "experiencing some issues". Os clientes querem concretude: "O login falha em ~30 % das tentativas. A API funciona normalmente. A web está disponível apenas em modo read-only."

Hosting: o princípio da infraestrutura independente

A página de status precisa rodar em uma infraestrutura diferente da do serviço monitorado. Se a sua região AWS cair, uma página de status hospedada na mesma região cai junto - exatamente no momento em que os clientes mais precisam dela.

Soluções práticas:

Hospedagem via um SaaS externo (ePulz.io, Better Stack, Atlassian Statuspage)
A sua própria página estática num CDN (Cloudflare Pages, Netlify) com o endpoint da API em outro lugar
Em último caso, uma página estática mínima no Cloudflare com texto atualizado manualmente

Subscribers: e-mail e webhook

Os clientes não querem atualizar a página de status o tempo todo. Uma boa página, portanto, suporta:

Email subscribers - no ePulz.io disponível para usuários logados com plano pago (coletamos inscrições apenas de contas verificadas, não de visitantes anônimos)
Webhook - para equipes que querem integrar o status no seu próprio Slack ou PagerDuty

Anti-pattern: esconder os problemas

A tentação de marcar uma queda como "degraded" em vez de "down" (ou de não mostrá-la de todo) é grande, mas míope:

Os clientes vão notar a queda de qualquer forma (via o próprio monitoring, tickets de suporte ou redes sociais)
Você perde confiança quando descobrem que o status indica "OK" durante uma queda evidente
Você perde a imagem real da tendência de uptime, de que precisa para a tomada de decisões interna

A melhor estratégia é a transparência radical. GitLab, Cloudflare e Stripe publicam post-mortems detalhados mesmo em erros embaraçosos, e a comunidade valoriza isso.

SEO e marca

Uma página de status deveria:

Estar num URL estável e fácil de lembrar para o status do serviço
Ter o seu próprio branding (logo, cores) - o cliente precisa ver que continua na sua página
Estar indexada no Google (melhor visibilidade ao pesquisar "[marca] down")
Estar vinculada a partir da página principal (rodapé "Status do serviço")

Conclusão

Uma página de status não é decoração. É uma ferramenta operacional que durante um incidente reduz a carga do suporte e constrói confiança a longo prazo. Investir algumas horas na configuração correta compensa logo na primeira queda maior.

Crie uma página de status em 5 minutos

Páginas de status ePulz.io com branding personalizado, email subscribers e incident timeline. 7 dias grátis.

Experimentar ePulz.io →