Como Criar uma Status Page

Uma página de status só vale a pena se ela se atualiza durante um incidente e se os clientes conseguem encontrá-la quando precisam. Estes passos constroem uma página movida por monitores reais desde o início, com contexto humano suficiente para reduzir ruído no suporte.

1. 1

   Decida quais componentes mostrar

   Liste as partes do produto que um cliente reconheceria e se importaria em ver separadamente: o site ou app principal, a API se outros integram com ela, checkout ou cobrança se podem falhar de forma independente, e qualquer serviço crítico em segundo plano que os clientes percebem quando para. Mantenha a lista curta e significativa; de três a seis componentes reconhecíveis valem mais do que vinte rótulos internos que ninguém fora da equipe entende.

2. 2

   Conecte cada componente a um monitor real

   Conecte cada componente da página ao monitor que já verifica aquilo: o mesmo check externo ou heartbeat que acompanha seu site no dia a dia. É isso que faz a página se atualizar sozinha: o componente fica vermelho quando o check subjacente falha e verde de novo quando recupera, sem etapa manual no meio. Se um componente não tem monitor por trás, adicione um ou deixe-o fora da página pública.

3. 3

   Publique e coloque o link onde as pessoas vão procurar

   Coloque o link da página de status onde ele realmente será encontrado durante um incidente: footer do site, docs, resposta automática do suporte, emails de onboarding e documentação de API são lugares comuns. Uma página de status tecnicamente no ar mas sem link em lugar nenhum não reduz tickets de suporte. Se clientes têm contratos ou SLAs, garanta que a página seja o lugar que você vai referenciar durante uma queda.

Depois que estiver no ar

Durante um incidente real, publique uma atualização curta assim que souber que algo está errado, mesmo antes de saber a causa: "estamos cientes e investigando" é melhor do que silêncio. Atualize de novo quando tiver mais informação e publique uma nota de resolução quando estiver corrigido. O status automático dos componentes cobre "no ar ou fora"; uma nota humana curta cobre impacto, escopo, alternativa e horário da próxima atualização. Ambos importam durante um incidente.

O que adicionar em seguida

Quando a página estiver no ar e corretamente conectada a monitores reais, adicione as peças que reduzem perguntas repetidas: um badge de histórico de uptime, assinaturas por RSS ou email e um modelo curto de incidente que a equipe possa reutilizar sob pressão. Se os monitores subjacentes incluem checks de TLS ou expiração de domínio, decida se eles merecem componentes visíveis para clientes ou se ficam melhor representados como parte do status do site principal: um certificado perto de expirar é um risco real, mas talvez não precise de uma linha pública própria.

Erros comuns a evitar

Listar todos os componentes internos. Uma página com uma dúzia de componentes que nenhum cliente reconhece é mais difícil de ler de relance do que uma com três ou quatro que realmente importam para eles. Guarde o detalhamento para uma visão interna se a equipe quiser uma.

Não conectar a nada. Uma página de status sem um monitor real por trás é só uma página estática que alguém precisa lembrar de atualizar, e isso falha exatamente quando todo mundo está mais ocupado. A fonte da verdade deve ser o monitor que já detecta o problema.

Publicar e não linkar em lugar nenhum. Como no passo 3, uma página de status no ar mas sem link no site, docs ou fluxo de suporte não será encontrada por ninguém no momento em que importa. Teste a descobribilidade do mesmo jeito que testa alertas: pergunte onde um cliente procuraria primeiro.