Monitorizar vários sites de clientes

Aos cinco sites, qualquer ferramenta serve. Aos vinte, a ferramenta deixa de ser o problema — o problema é que chega um alerta a dizer Monitor 14 is down e tu não fazes ideia de quem é o Monitor 14.

Monitorizar vários sites de clientes é um problema de organização antes de ser um problema de software. E as decisões que o resolvem tomam-se todas antes de configurar o primeiro monitor.

Decide primeiro o que é que estás a vigiar.

O erro que se paga mais tarde é configurar um monitor por site e considerar o trabalho feito. Um site não é uma coisa — são várias, e falham de maneiras diferentes.

Para cada cliente, vale a pena decidir conscientemente quais destes entram:

A página inicial. Obrigatória, sempre.
A página que dá dinheiro. O carrinho, o formulário de marcação, a página de contacto. É a que dói quando parte, e é frequentemente a que ninguém vigia.
O certificado TLS. Não é uma verificação de disponibilidade, é uma data. E é a falha mais evitável de todas.
O endpoint de API, se houver alguma coisa a consumir o site.

O segundo item merece atenção porque é onde a diferença se nota. Se a página inicial é estática e o formulário depende da base de dados, uma verificação só à página inicial pode dar verde com a parte útil do site em baixo.

E cuidado com a contagem: é aqui que os planos gratuitos acabam. “50 monitores grátis” com quatro verificações por cliente dá doze clientes, não cinquenta.

A convenção de nomes, que é a parte mais barata e mais útil.

Escolhe um formato e não o quebres nunca:

Cliente — O quê
Padaria Silva — Site
Padaria Silva — Loja
Padaria Silva — Certificado

O cliente à cabeça, porque é o primeiro dado de que precisas quando o alerta toca. O que é a seguir, porque é o que decide a urgência. Sem hífen a meio do nome do cliente, para a ordenação alfabética continuar a funcionar.

Parece pequeno. É a diferença entre um alerta accionável e um alerta que obriga a abrir o painel para perceber do que se trata — e num telemóvel, às onze da noite, essa diferença é grande.

Três níveis de urgência, e não um.

O erro seguinte é tratar todos os sites da mesma maneira. Uma loja online em campanha e o site institucional de uma associação não merecem o mesmo alerta às três da manhã.

Um esquema simples que aguenta uma carteira grande:

Nível 1 — acorda-me. Lojas online, marcações, qualquer coisa em que uma hora de falha tem consequência directa. Alerta imediato no canal que tens no telemóvel.

Nível 2 — avisa durante o dia. Sites institucionais com tráfego. Alerta no canal de trabalho, sem urgência nocturna.

Nível 3 — resumo. Sites com pouco movimento, projectos parados, staging. Basta saber que estiveram em baixo, não é preciso saber no momento.

Se a tua ferramenta não permite isto, o remédio caseiro é ter todos os alertas a ir para um canal de trabalho e só os de nível 1 a irem também para uma conversa com notificação activa no telemóvel.

Onde os alertas devem chegar.

Não é o email. Um alerta que aterra numa caixa que abres duas vezes por dia não é um alerta — é um registo histórico com outro nome.

Duas regras práticas:

Um canal por cliente, quando forem muitos. O site do cliente A no canal do cliente A. Numa equipa, é a diferença entre saber de quem é o problema e três pessoas abrirem o mesmo painel para descobrir.

Um webhook resolve o que a ferramenta não tem. Se o canal que usas não está na lista da ferramenta, um webhook leva o incidente em JSON para onde quiseres. É a peça que impede a lista de canais de ser uma prisão, e é a primeira coisa a confirmar antes de escolher.

O ritual mensal, que substitui a ronda diária.

Com monitorização a funcionar, a ronda da manhã deixa de fazer sentido. O que faz sentido é uma passagem por mês, de vinte minutos, com quatro perguntas:

Que sites tiveram incidentes? Se um cliente aparece três meses seguidos, o problema é o alojamento e a conversa a ter é essa.
Que sites estão mais lentos do que há três meses? É o que os alertas nunca apanham, e é o aviso antecipado de metade das falhas.
Que certificados expiram nos próximos sessenta dias?
Que sites entraram ou saíram da carteira? Monitores de clientes antigos consomem lugares e geram alertas que ninguém trata.

Ao fim de um ano, esta passagem mensal é também o material dos relatórios — e o argumento na conversa de renovação da avença.

Os sítios onde isto costuma partir.

O histórico apagado. Muitos planos gratuitos guardam sete ou trinta dias. Se usas a monitorização como argumento comercial, o histórico é o produto e o alerta é só a parte que faz barulho. Se a tua ferramenta apaga, exporta todos os meses.

Alertas a mais. Uma ferramenta que dispara a cada soluço de rede é uma ferramenta que aprendes a ignorar — e no dia em que o alerta é verdadeiro, também o ignoras. Confirmar a falha com um segundo pedido antes de avisar não é um detalhe de implementação; é o que mantém os alertas com significado.

Sites de clientes que já não são clientes. Faz parte da limpeza mensal, e ninguém a faz.

O que isto não resolve.

Não resolve o que se passa dentro do site. Um formulário que deixou de enviar email, um pagamento que rebenta no último passo, um stock desincronizado — tudo isso responde 200 e conta como online em qualquer ferramenta desta categoria.

Também não resolve a parte difícil, que é ter tempo para responder quando o alerta chega. Saberes primeiro só é uma vantagem se puderes fazer alguma coisa com essa informação — e se a tua avença não previr resposta fora de horas, é uma conversa a ter com o cliente e não com a ferramenta.

A outra metade disto é a vista: o que um painel resolve, o que não resolve e as três coisas que decidem se serve está em painel único vs vinte separadores.

A De Olho está a ser construída para este caso concreto: vista única ordenada pelo que está pior, agrupada por cliente, alertas em todos os canais sem taxa por canal, e histórico que não expira. Abre em 2026 — quem entrar na lista de espera sabe primeiro e fica com o preço de lançamento.