Monitoramento de site e sistemas: uptime, alertas e o que medir

Monitoramento de sites e sistemas é a verificação automática e contínua de que o que a empresa publica está funcionando, com aviso para uma pessoa quando deixa de funcionar. Serve para qualquer empresa que vende, atende ou opera por um site, uma loja virtual, um portal de cliente ou um sistema interno que roda em servidor.

Sem monitoramento, quem descobre a queda é o cliente. O pedido que não fecha no checkout, o formulário de contato que devolve erro desde sexta-feira, o certificado HTTPS que venceu e fez o navegador exibir aviso de site inseguro. A equipe só fica sabendo quando alguém liga reclamando, e aí o problema já tem horas.

Monitorar bem não é encher o celular de notificação. É escolher o que medir, definir quando um número vira alerta e ter uma rotina para cada incidente não se repetir. O monitoramento não impede a falha: encurta o tempo entre ela acontecer e alguém agir.

O que é uptime e quanto 99,9% significa em minutos

Uptime é a porcentagem do tempo em que o serviço esteve no ar e respondendo, dentro de um período (mês ou ano). Os contratos de hospedagem e de sistemas costumam prometer um número assim, e a diferença entre eles parece pequena até virar minutos.

As contas abaixo usam um mês de 30 dias (43.200 minutos) e um ano de 365 dias (525.600 minutos):

Num mês de 31 dias, os 99,9% sobem para 44,6 minutos. A regra de bolso: cada nove a mais (de 99% para 99,9%, de 99,9% para 99,99%) divide por dez o tempo de parada permitido.

Dois cuidados ao ler um contrato. Primeiro, veja de onde e como o fornecedor mede: servidor que responde não quer dizer site que funciona. Segundo, veja o que fica fora da conta, porque manutenção programada quase sempre fica. É por isso que vale ter uma medição própria, independente da do fornecedor.

Monitoramento externo e interno: qual a diferença

Existem dois pontos de vista, e eles se completam. O livro de engenharia de confiabilidade do Google, no capítulo sobre monitoramento de sistemas distribuídos, chama o primeiro de caixa-preta e o segundo de caixa-branca.

• Monitoramento externo (sintético): um serviço fora da sua infraestrutura acessa o site em intervalo fixo, de uma ou mais regiões, do jeito que um cliente faria. Pode ser uma requisição simples à página inicial ou uma transação sintética, que repete um fluxo inteiro: abrir o login, entrar com um usuário de teste, buscar um produto. Ele mede o sintoma: está quebrado agora, para quem está de fora.
• Monitoramento interno: métricas e registros coletados dentro dos servidores e do sistema, como uso de processador, memória, disco, conexões com o banco de dados, tamanho das filas e erros da aplicação. Ele ajuda a explicar a causa e, muitas vezes, avisa antes de o cliente perceber.

Uma empresa pequena pode começar só com o externo, que é o que responde se o cliente está sendo atendido. O interno entra quando existe servidor próprio, sistema sob medida ou integração rodando em fila.

O que medir além de o site estar no ar

O mesmo capítulo do Google resume o essencial em quatro sinais: latência (tempo de resposta), tráfego (volume de uso), erros e saturação (o quanto o recurso mais apertado está perto do limite). Traduzido para a rotina de uma PME, a lista fica assim:

• Disponibilidade com conteúdo: não basta o servidor devolver o código 200 (sucesso). Configure o monitor para procurar um texto que só aparece na página certa, como o nome do botão de compra. Página em branco com código 200 é falha que o teste simples não pega.
• Tempo de resposta: acompanhe a tendência, não o número isolado. Um site que respondia em meio segundo e passou a levar três está avisando alguma coisa. Isso é diferente da velocidade percebida no navegador, tratada no guia de Core Web Vitals e velocidade do site.
• Erros 5xx: códigos que começam com 5 indicam falha do lado do servidor (500 é erro interno; 502 e 504 indicam que o servidor da frente não recebeu resposta válida, ou não recebeu a tempo, do sistema que está atrás dele; 503 é serviço indisponível). Meça a taxa, a porcentagem de requisições com erro, e não só a contagem.
• Certificado HTTPS: a data de validade precisa ser vigiada. O Let's Encrypt, autoridade que emite certificados gratuitos, deixou de enviar e-mail de aviso de vencimento em junho de 2025 e anunciou a redução da validade de 90 para 45 dias até 2028, com a recomendação expressa de ter monitoramento que avise quando a renovação não acontece.
• Domínio: domínio vencido derruba o site e o e-mail ao mesmo tempo. A data de vencimento no registro e o cartão cadastrado para renovação precisam de alerta com antecedência. O guia sobre domínio, DNS, e-mail e hospedagem mostra o que a empresa deve controlar.
• Disco: porcentagem de uso e velocidade de crescimento. Disco cheio derruba o banco de dados, trava o envio de e-mail e pode corromper arquivo no meio da gravação.
• Filas: emissão de nota, envio de e-mail, sincronização com o ERP. Vigie o tamanho da fila e a idade do item mais antigo. Fila que só cresce é integração parada, mesmo com o site no ar.
• Backup que falhou: o alerta de falha é o óbvio. O menos óbvio é o backup que nem rodou, e para esse o monitor precisa esperar um sinal (a tarefa avisa quando termina) e disparar quando o sinal não chega. O texto sobre a regra 3-2-1 e o teste de restauração explica por que o aviso de sucesso também não basta.

Como configurar alertas que não viram ruído

O risco de um monitoramento mal calibrado é a equipe aprender a ignorar o alerta. Depois da décima notificação falsa da semana, a verdadeira passa batido. O livro do Google é direto: todo alerta que chama uma pessoa deve exigir raciocínio, e alerta que só pede uma resposta mecânica não deveria chamar ninguém.

Quatro decisões resolvem a maior parte do ruído:

1. Limiar. Defina o número a partir do comportamento normal de cada sistema, e com duração. "Tempo de resposta acima de 3 segundos por 5 minutos seguidos" é um alerta; "tempo de resposta acima de 3 segundos uma vez" é ruído.
2. Confirmação. Só avise depois de falhas consecutivas e, no monitor externo, a partir de mais de uma região. Uma oscilação de rede entre o monitor e o servidor não é queda do site.
3. Quem recebe. Alerta mandado para um grupo de doze pessoas é responsabilidade de ninguém. Defina um responsável por sistema e um canal por gravidade: o crítico vai para o celular, o informativo vai para o e-mail ou para um canal de equipe.
4. Escalonamento. Se o responsável não reconhecer o alerta em um prazo combinado, ele vai para o substituto, e depois para quem decide. Sem essa regra, o alerta das duas da manhã fica esperando até as nove.

Separe também dois níveis de gravidade. "Precisa de alguém agora" cobre site fora do ar, checkout com erro, backup crítico que não rodou. "Resolve no horário de trabalho" cobre disco em 80%, certificado vencendo em 14 dias, fila mais lenta que o normal. Uma vez por mês, revise os alertas disparados: o que ninguém precisou tratar é candidato a ser ajustado ou apagado.

Página de status: quando vale a pena

Página de status é uma página pública, ou interna, que mostra o estado de cada serviço e o histórico de incidentes. Ela faz sentido quando clientes dependem do seu sistema para trabalhar, como num portal de cliente, num sistema oferecido por assinatura ou numa loja com muitos pedidos por hora. Para um site institucional, geralmente é exagero.

Três regras para ela funcionar:

• Hospede fora da sua infraestrutura. Página de status no mesmo servidor do sistema cai junto com ele.
• Publique fatos, com horário. O que está afetado, desde quando e quando sai a próxima atualização. Sem palpite técnico sobre a causa enquanto ela não foi confirmada.
• Atualize até o fim. Incidente aberto sem atualização por horas gera mais chamado do que a própria queda.

Mesmo sem página pública, uma versão interna ajuda: o atendimento sabe o que responder ao cliente sem interromper quem está consertando.

Logs: o que guardar para investigar depois

Log é o registro com data e hora do que o sistema fez: quem acessou, qual página, qual erro aconteceu, quem entrou com qual usuário. O monitoramento avisa que algo quebrou; o log conta o que aconteceu antes.

• Centralize fora do servidor. Se o servidor cair ou for invadido, o log que ficou só nele some junto ou pode ser apagado.
• Sincronize o relógio de todas as máquinas. Comparar registros de servidores com horários diferentes vira adivinhação.
• Defina retenção. Tempo suficiente para investigar um problema descoberto tarde, sem guardar para sempre.
• Não registre senha, token nem dado pessoal desnecessário. Log também é base de dados e também está sujeito à LGPD.

O que fazer depois de um incidente

Quando o sistema volta, o trabalho não terminou. O Google chama esse registro de postmortem e o define, no capítulo sobre cultura de postmortem, como o registro escrito do incidente, do impacto, das ações de contenção, das causas e das ações para que ele não se repita. Numa PME, isso cabe numa página:

1. Registro. Linha do tempo com horários: quando começou, quando o alerta chegou, quando alguém agiu, quando voltou. E o impacto: quantos pedidos, quais clientes, quanto tempo.
2. Causa. O que quebrou e por que o monitoramento não pegou antes, se não pegou. Falha que foi descoberta por cliente é falha de monitoramento também.
3. Correção. O conserto imediato e as ações preventivas, cada uma com responsável e data. Ação sem dono não sai do papel.

O registro é sem culpados: o foco está no processo que permitiu o erro, não em quem apertou o botão. Equipe que é punida por relatar incidente aprende a esconder incidente.

Por onde começar o monitoramento da sua empresa

Uma ordem prática para a primeira semana:

1. Liste o que está publicado: domínios, sites, sistemas, certificados, tarefas de backup e integrações.
2. Coloque monitor externo com verificação de conteúdo na página inicial e nas páginas que geram receita, como checkout, login e formulário de contato.
3. Crie alertas de vencimento para certificado e domínio, com antecedência de algumas semanas.
4. Defina quem recebe cada alerta, o substituto e o prazo de escalonamento.
5. No primeiro incidente, escreva o registro de uma página, mesmo que a queda tenha sido curta.

No serviço de monitoramento de sites e sistemas, a Locomotiva começa por esse inventário e ajusta os limiares a partir do comportamento normal de cada sistema, para o alerta chegar quando existe algo a fazer.