Página de status e comunicação de incidente

Quando o serviço cai, o cliente descobre antes de você avisar. A pergunta não é se ele vai saber — é se ele vai saber por você ou pelo próprio erro na tela.

A diferença entre as duas coisas é quase toda a diferença de confiança depois do incidente.

Por que a página de status importa mais do que parece

Ela responde, sem ninguém precisar perguntar, a única dúvida que o cliente tem naquele momento: é comigo ou é com vocês?

Enquanto essa dúvida existe, ele reinicia o servidor dele, revisa a chave de API, culpa o próprio código. Quando ela é respondida, ele espera.

Um efeito colateral prático: o volume de chamados durante uma queda cai muito quando existe página de status atualizada. O tempo que o suporte gastaria repetindo a mesma resposta vira tempo consertando.

Onde ela precisa estar

Fora da sua infraestrutura. Página de status hospedada no mesmo lugar do produto cai junto com ele — e cai exatamente quando é necessária. É o erro mais comum, e o mais constrangedor.

Em endereço previsível. status.seudominio.com. Ninguém procura link de status quando está com pressa.

Linkada do rodapé, em todas as páginas, o tempo todo. Descobrir onde fica o status durante a queda é tarde demais.

O que publicar durante o incidente

O que está afetado, em termos do cliente. "Criação de pedidos está falhando" — não "degradação no serviço de provisionamento". Ele quer saber o que dele parou.

Desde quando. Ajuda a correlacionar com o que ele viu.

O que ainda funciona. Tão importante quanto o que quebrou. Se só a compra caiu e a consulta segue, diga — muita gente vai parar tudo achando que caiu inteiro.

Quando é a próxima atualização. Esse é o item que mais reduz ansiedade e o que mais gente esquece. "Próxima atualização em 30 minutos" transforma espera indefinida em espera com prazo. E cumpra o prazo mesmo sem novidade: "ainda investigando, próxima em 30 minutos" é atualização válida.

O que não publicar: causa provável antes de ter certeza. Retratar diagnóstico errado custa mais credibilidade do que ter demorado a diagnosticar.

O ritmo

Primeira mensagem em minutos, não em horas. Ela não precisa ter diagnóstico. "Estamos investigando falhas na criação de pedidos" já faz o trabalho principal, que é confirmar que você sabe.

Atualize no prazo prometido, mesmo sem avanço.

Avise quando resolver, com a mesma clareza. E não some depois — o fim do incidente é quando você recupera a confiança.

Depois: o relato

Incidente que afetou cliente pagante merece um relato público, curto e honesto:

• o que aconteceu, em linguagem clara;
• por quanto tempo e o que foi afetado;
• por que aconteceu, sem apontar pessoa;
• o que muda para não repetir.

O último item é o que importa. Relato sem mudança concreta lê como desculpa formal, e teria sido melhor não escrever.

Evite culpar terceiro. "Nosso fornecedor caiu" é verdade e é irrelevante para quem contratou você — a escolha do fornecedor foi sua. O que interessa é o que você vai fazer para que a queda dele não vire a sua.

Antes de tudo isso: monitore

Página de status só funciona se alguém souber que caiu. E o pior cenário é o cliente avisar.

O mínimo é uma sonda externa batendo numa rota que exercita o caminho real, não uma rota que só devolve "ok" sem tocar em banco nem em fornecedor. Verificação de saúde que responde saudável com o serviço quebrado é pior que não ter nenhuma — ela dá falsa tranquilidade.

Um cuidado relacionado: se um componente entrega para um destino que não existe mais e ninguém percebe, o sintoma é o silêncio. Fila que drena para lugar nenhum e verificação que responde saudável produzem exatamente isso.

O básico que resolve a maior parte

Uma página fora da sua infraestrutura, com link no rodapé. Uma sonda externa que testa o caminho real. Um combinado interno de quem escreve a primeira mensagem e em quanto tempo.

Três coisas, nenhuma cara, e elas cobrem quase todo o dano reputacional de uma queda.

Se o assunto for o outro lado — como o seu sistema se comporta quando um fornecedor cai —, timeout, retentativa e circuit breaker trata da parte técnica, e como monitorar uma integração em produção, de como descobrir cedo.

Do nosso lado, é por isso que os números virtuais têm mais de um fornecedor por trás: a queda de um não precisa virar incidente para você.