Manutenção significa saber que o formulário entrega hoje, não que o servidor responde 200.

O percurso de um pedido até uma pessoa, não a disponibilidade do servidor. `GET /api/health/contact` verifica, numa única chamada, duas coisas: que o token do canal de notificações continua válido — através de uma chamada real ao fornecedor, com timeout de 8 segundos — e que o registo de pedidos pode ser escrito. Responde 200 quando ambas são verdadeiras e 503 quando não são. Você pode chamá-lo já neste site: é público, precisamente porque não devolve mais do que valores lógicos.

Porque a parte visível continua a funcionar. A página carrega, o botão responde, o servidor devolve 200 em todas as páginas — só se rompe a ligação final, que não tem interface. Neste site, o token do bot de notificações foi revogado: o fornecedor respondia `401 Unauthorized`, a rota devolvia 500, e o pedido não era escrito em lado nenhum. Três falhas reais em aproximadamente sete horas, visíveis apenas no registo de erros do processo. Por isso o registo é agora escrito antes da entrega: mesmo que a notificação falhe, o pedido existe.

O pedido já está escrito no registo com um identificador próprio, e a segunda linha do registo diz `failed` e o motivo. O visitante recebe uma resposta distinta — “recebemos o pedido, mas não foi possível notificar” — não um sucesso falso. O código de resposta diferencia a causa: 502 significa que o fornecedor respondeu mal, 503 que faltam credenciais nossas. Às 3 da manhã, a diferença entre os dois decide se você telefona a alguém ou não.

Não sem gate. A publicação executa `npm audit` ao nível `high` e para em vulnerabilidades deste nível se a continuação não for confirmada explicitamente; verifica primeiro também a memória disponível do servidor, com limite de 500 MB, porque uma construção iniciada num servidor limitado deixa a aplicação parada. A construção é feita a partir de um estado limpo: o diretório de construção e as dependências são apagados, a instalação é feita a partir do ficheiro de bloqueio. O que é atualizado automaticamente e o que passa por verificação humana é definido por projeto, não implicitamente.

Através de um script de verificação executado após a publicação, que abre cada página de produto e falha se faltar o código 200, a âncora das perguntas, a âncora do exemplo ou o endereço canónico. Em seguida, verifica o mapa do site — para conter cada produto e não conter variantes de idioma que não possam ser abertas — e o `robots.txt`, para não bloquear recursos de renderização. Cada verificação da lista corresponde a algo que já se estragou uma vez. O script é entregue juntamente com o projeto.

O processo é reiniciado automaticamente acima do limiar de 500 MB, com 4 segundos de atraso entre tentativas e aumento exponencial, mas pára após 10 reinícios instáveis num intervalo curto. Isto é importante: um loop de queda que se reinicia infinitamente parece saudável num painel e consome o servidor em silêncio. Preferimos que o processo fique parado e visível.

24 meses, aplicados pelo código, não apenas declarados: o limiar é uma variável com o valor predefinido de 730 dias, e os ficheiros mais antigos são apagados a cada nova gravação, sem agendador que possa ser esquecido. O diretório tem permissões `0700`, os ficheiros `0600`, e o caminho fica fora do diretório de versão, para que o histórico sobreviva à publicação. O endereço IP não é guardado por inteiro: é truncado para `/24` no IPv4 e `/48` no IPv6, lendo o último hop do cabeçalho, não o primeiro — o primeiro é enviado pelo cliente e não significa nada.

Acontece, e normalmente esses são os caros. A mesma passagem pelo código que reparou o formulário revelou duas coisas que ninguém tinha assinalado: o limite de pedidos podia ser contornado por completo, porque se lia o primeiro elemento do cabeçalho de endereços redirecionados — precisamente o que o cliente envia; e uma rota que iniciava chamadas telefónicas estava aberta anonimamente, à nossa custa, embora o componente que a usava já tivesse sido desmontado. Ambos foram reparados e verificados em produção. O que não podemos prometer é que encontremos tudo; o que podemos prometer é que reportamos também o que vocês não pediram.

Não é um serviço de segurança com monitorização contínua e não é um centro de operações. Não garantimos uma percentagem de disponibilidade sem uma medição que a sustente — e, para que fique claro, neste momento não publicamos uma cifra dessas para o nosso próprio site. Não assumimos a responsabilidade por uma plataforma de terceiros a que não temos acesso. E não tratamos uma página que responde 200 como prova de que está tudo a funcionar: foi exatamente esse o problema a partir do qual começou tudo o que está escrito acima.