Monitoramento de sistema: como saber do erro antes do cliente

Toda empresa com sistema no ar já viveu esta cena. O WhatsApp toca, é um cliente, e a mensagem diz que o site não abre, que o pagamento não passa ou que o aplicativo trava no login. Você liga para quem cuida do sistema, e a pessoa do outro lado também está sabendo agora.

O problema não é o erro. Todo sistema vai ter erro em algum momento. O problema é descobrir pelo cliente, depois que ele já perdeu tempo, já desistiu da compra ou já reclamou em público. Neste guia eu mostro o que um monitoramento de verdade precisa medir, quanto custa não ter, e o que pedir ao fornecedor que cuida do seu produto.

Descobrir a falha pelo cliente ainda é comum

Parece coisa de empresa pequena e desorganizada. Não é. Na pesquisa de 2025 da New Relic, feita com 1.700 profissionais de TI e engenharia em 23 países, 41% dos líderes disseram que ainda ficam sabendo das interrupções por meios ineficientes: reclamação de cliente, chamado aberto ou checagem manual.

A mesma pesquisa mostra o que isso faz com o time. Os engenheiros gastam 33% do tempo apagando incêndio ou lidando com interrupções. Um terço do que você paga em desenvolvimento vai para correr atrás do problema, em vez de construir o que o negócio precisa.

E a demora custa. Mesmo as equipes com monitoramento completo levam, em média, 28 minutos para detectar uma queda, segundo a New Relic. As outras levam 7 minutos a mais. Em um sistema que vende, agenda ou atende, cada um desses minutos tem cliente do outro lado.

Quanto custa uma queda

Os números das pesquisas globais são de empresas grandes, mas a proporção vale para qualquer tamanho. O relatório anual de quedas do Uptime Institute, divulgado em maio de 2026, mostra que 57% das empresas disseram que a última grande queda custou mais de US$ 100 mil. Pelo segundo ano seguido, uma em cada cinco passou de US$ 1 milhão.

O mesmo relatório traz um dado que interessa a quem tem sistema na nuvem. Em nove anos de quedas registradas publicamente, cerca de dois terços vieram de fornecedores de terceiros: nuvem, internet, telecomunicações e data centers alugados. A New Relic aponta na mesma direção. As três causas mais comuns de quedas graves são falha de rede, falha de fornecedor de nuvem ou serviço de terceiro, e publicação de código novo.

Traduzindo para o seu caso: boa parte do que vai quebrar o seu sistema não está no código que você pagou. Está no gateway de pagamento, no envio de e-mail, no serviço de login, na hospedagem. E a outra parte vem da própria atualização que o seu time publicou na sexta à tarde. Monitorar é cobrir as duas.

O que medir: os quatro sinais básicos

O Google publicou no livro de engenharia de confiabilidade dele, o Site Reliability Engineering, quatro sinais que todo sistema voltado para usuário deveria medir. Em linguagem de negócio:

1. Tempo de resposta. Quanto o sistema demora para responder. Uma página que abre em 8 segundos está no ar, mas o cliente já foi embora.
2. Volume de uso. Quantas pessoas ou pedidos o sistema está recebendo. Uma queda repentina de acessos às 10 da manhã de uma terça é sinal de problema, mesmo sem nenhum erro aparente.
3. Erros. A proporção de pedidos que falham. Inclui o erro que aparece na tela e o que não aparece, como um cadastro que parece salvo e não foi.
4. Saturação. O quanto o sistema está perto do limite: disco, memória, banco de dados, cota de um serviço de terceiro. É o sinal que avisa antes de quebrar.

O mesmo livro resume a função de tudo isso numa frase: o monitoramento existe para o sistema “nos dizer quando está quebrado, ou talvez o que está prestes a quebrar”. E traz uma regra que vale ouro para quem paga a conta: todo alerta precisa exigir uma ação. Alerta que ninguém precisa resolver vira ruído, e ruído faz o time ignorar o alerta que importa.

O que os quatro sinais não pegam

Tem um tipo de falha que nenhum desses gráficos mostra: o sistema no ar, rápido, sem erro, e com o dado errado. O relatório soma em dobro. O estoque fica negativo. O desconto aplica duas vezes. A agenda aceita dois clientes no mesmo horário.

Esse é o erro mais caro, porque demora a aparecer. Quando alguém percebe, já são semanas de número errado em decisão de negócio. Para pegar esse tipo de falha, o monitoramento precisa olhar também para os dados: totais que não batem, registros que fogem do padrão, processos que deveriam ter rodado e não rodaram.

Por isso eu separo o monitoramento em três camadas:

• Está no ar? Verificação de fora para dentro, a cada poucos minutos, nas páginas e rotas que mais importam: entrada, login, pagamento, formulário de contato.
• Está funcionando? Tempo de resposta, taxa de erro e saturação, por dentro do sistema, com registro de cada falha.
• Está certo? Conferência dos dados e dos processos que fazem o negócio andar.

Muito sistema no ar tem só a primeira camada. Ela avisa quando tudo cai, mas não quando o sistema funciona errado.

O que pedir ao fornecedor que cuida do seu sistema

Monitoramento não é uma ferramenta que você compra e liga. É uma rotina com dono. Antes de fechar ou renovar um contrato de manutenção, confira se ele responde a estas perguntas por escrito:

• O que é verificado e com que frequência. Quais páginas, quais rotas, quais processos. “O sistema todo” não é resposta.
• Quem recebe o alerta. Uma pessoa com nome, não um e-mail que ninguém lê.
• Em quanto tempo alguém começa a resolver. Separado por gravidade: pagamento parado não espera segunda-feira.
• Como você fica sabendo. O alerta técnico vai para quem corrige. Você recebe o que aconteceu, quanto durou, quem foi afetado e o que foi feito.
• O que entra no relatório do mês. Disponibilidade, erros mais frequentes, tempo de resposta e o que foi melhorado.
• Em nome de quem estão as contas. As ferramentas de monitoramento e o histórico de alertas também são parte do seu sistema.

Se você está montando esse orçamento agora, escrevi sobre quanto custa manter um sistema ou app no ar, com as linhas que o monitoramento precisa ocupar. E se o produto foi feito com ferramentas de IA, o risco de erro silencioso costuma ser maior. Expliquei o porquê em o custo de manutenção do vibe coding.

Como fazemos no Studio

No Studio, todo sistema que entregamos sai com um agente de IA que roda todo dia. Ele aponta falhas, sugere melhorias e confere se os dados fazem sentido. É a terceira camada, a do “está certo?”, que quase ninguém cobre e que costuma ser a mais cara quando falha.

O restante segue o mesmo princípio que usamos no projeto. O preço é fechado depois do diagnóstico, e o prazo vai escrito no contrato. O código, os arquivos e os acessos ficam em nome do cliente, incluindo as contas das ferramentas. A equipe de devs é nossa, e usamos Claude Code e Figma no design e no build.

Menos peças também significa menos lugares para uma falha se esconder. Na LCX, empresa de turismo com operação em mais de 10 países da América do Sul, um sistema por país virou um sistema só, no ar em 29 dias. Um sistema para monitorar, em vez de um por país.

Se hoje quem avisa que o seu sistema caiu é o cliente, esse é o primeiro trabalho do nosso serviço de manutenção e evolução de sistemas: colocar alguém, e alguma coisa, olhando antes dele.