O site caiu às 3h da manhã. Quem é que o descobriu primeiro?

Há uma verdade incómoda na gestão de sites: um servidor em baixo não faz barulho. Não há erro no ecrã do utilizador que nos avise, não há email a chegar à nossa caixa de correio. Simplesmente deixa de haver site – e a primeira pessoa a saber é quase sempre o cliente, ou pior, um cliente que desistiu e foi comprar a outro lado.

É por isso é que na Make It Digital, não confiamos na sorte nem no “depois vemos”. Temos monitorização ativa 24 horas por dia. Este artigo explica como usamos o UptimeRobot e, mais importante, como pensamos sobre monitorização – porque a ferramenta é a parte fácil.

Um HTTP 200 não significa que o site está bem

O erro mais comum é assumir que, se o servidor responde “200 OK”, está tudo a funcionar. Na prática, é possível devolver 200 e, ao mesmo tempo, mostrar uma página com base de dados em baixo, um carrinho de compras vazio ou um formulário que não grava nada. O código de estado diz que o servidor respondeu — não que o negócio está a funcionar.

Por isso, monitorizamos em várias camadas:

• HTTP/S: confirma que a página responde dentro de um tempo aceitável — a resposta mais básica.
• Keyword: verifica se uma palavra-chave esperada aparece no HTML. Se o texto desaparecer, é sinal de erro mesmo com um 200.
• Porta: vigia portas específicas (SMTP, base de dados, FTP), onde uma falha costuma ser invisível para o visitante.
• Ping: confirma que a máquina está viva, mesmo quando a aplicação está a demorar.
• Cron / Heartbeat: recebe um sinal periódico de tarefas agendadas. Se a tarefa deixa de bater, sabemos — antes que os dados se acumulem errados.

Alertas: nada serve se ninguém os lê

Um alerta que cai numa caixa de correio que ninguém vê é teatro. Configuramos os avisos para canais que as pessoas realmente leem, e definimos uma lógica de escalonamento:

• Alerta por email e Slack para a equipa — imediato.
• SMS para situações críticas, fora de horas, quando o site está mesmo em baixo.
• Confirmação por falsos positivos: um timeout isolado dispara aviso, mas só se repetir é que acorda alguém. Ninguém quer ser chamado às 3h por um blip de rede.

Esta é a mesma lógica de rigor que aplicamos à configuração dos servidores — como já explicámos em segurança para lá do HTTPS: o que não se mede, não se controla.

A status page pública

Usamos também uma página de estado pública. Quando algo falha, o cliente pode ver num relance se o problema é geral ou só da sua conta — sem ter de abrir um ticket nem escrever-nos a perguntar “o site está em baixo para todos?”. Poupa tempo a todos e transmite transparência. Num negócio que vive de confiança, isso vale mais do que parece.

Quando o alerta dispara

Um alerta não é um fim — é o início de um processo:

• Confirmar se é real ou falso positivo (verificar de outra rede, outro dispositivo).
• Isolar a causa: carga do servidor, base de dados, certificado expirado ou erro de código.
• Comunicar ao cliente, mesmo que ainda não haja solução — o silêncio é o pior estado.
• Registar o incidente e o que se aprendeu. Um problema repetido deve-se tornar uma melhoria, não um hábito.

Em resumo

• Monitorização não é ver se o site responde — é saber se o negócio continua a funcionar.
• Vários tipos de monitor (HTTP, keyword, porta, cron) cobrem o que um só não vê.
• Alertas só contam se chegarem a alguém que os leia, e no canal certo à hora certa.
• Bem configurado, o sistema é invisível — e é exatamente isso que queremos.

Se não sabe quem é avisado quando o seu site cai — ou se não há ninguém — vale a pena falarmos. A monitorização é um dos alicerces da saúde técnica de um site: quando falha, tudo o resto falha com ela.