Como sabes que a tua app está em baixo?

O que é e porque importa

Monitorizar uma app quer dizer saber que se avariou antes que alguém te diga. Sem isso, se o site vai abaixo de noite, descobres de manhã. E muitas vezes ninguém te escreve a avisar: quem encontra a app avariada fecha-a e pronto.

Para mim, a monitorização são três peças que trabalham juntas:

• A verificação de fora: um serviço que, de poucos em poucos minutos, abre o teu endereço, como faria um utilizador, e vê se responde.
• O registo de erros: o sítio onde vai parar cada erro da app, com o stack trace, ou seja, a linha de código onde se avariou.
• O aviso: o email ou a notificação no telemóvel que te chega quando um dos dois encontra alguma coisa.

A verificação tem de estar fora da tua app: se a app está em baixo, não te pode dizer ela. O registo de erros, pelo contrário, diz-te o que avaria mesmo quando a app responde.

E se ligares o Claude Code ao registo de erros, quando dispara o alerta não começas do zero.

1. O que uso

Uso dois serviços. Não são os únicos: com outros o processo é o mesmo.

Para os erros: Sentry

Cada erro da app chega lá com o stack trace, e é de lá que saem os avisos. O plano gratuito chama-se Developer: é para um só utilizador e manda os avisos por email.

Para a verificação a cada 5 minutos: UptimeRobot

Abre o teu endereço e, se não responder, avisa-te por email e com uma notificação na app do telemóvel. Plano gratuito: 50 monitores, verificação a cada 5 minutos; as condições de utilização confirma-as no site deles.

2. A meia hora

Faz-se uma só vez, em cerca de meia hora se a app já estiver online.

Sentry na app

1. Cria um projeto no Sentry. Mostra-te o DSN, a chave do projeto: é o endereço para onde a tua app manda os erros. Voltas a encontrá-lo nas definições do projeto, em Client Keys (DSN).
2. Copia-o e escreve ao Claude Code:

Adiciona o Sentry a esta app usando o DSN que te dou, numa variável de ambiente e não no código. Depois faz disparar um erro de teste e diz-me como verifico que chegou.

O erro de teste é a parte que conta: enquanto não o vires chegar ao Sentry, não sabes se funciona. Depois vê nos avisos do Sentry se há uma regra para os erros novos.

Uma página para verificar

A página inicial às vezes carrega mesmo com a base de dados parada. Por isso dou à verificação uma página própria:

Cria uma página /health que responde ok só se a app e a base de dados estiverem a funcionar.

Quando alguma coisa não está bem, a página tem de responder com um código de erro. Se mostrar uma página normal a dizer «erro», a verificação vê-a abrir e acha que está tudo bem. Se o Claude ainda não o fez, acrescento:

Se alguma coisa não funcionar, /health tem de responder com um código de erro, tipo 503, e não pode mostrar detalhes internos como palavras-passe, endereços da base de dados ou mensagens de erro completas.

A verificação a cada 5 minutos

1. No UptimeRobot, cria um monitor novo em [endereço da tua app]/health, com uma verificação a cada 5 minutos.
2. Como avisos, ativa o email e a app no telemóvel, onde inicias sessão com a mesma conta.
3. Para o testar, põe por um momento um endereço errado no monitor e vê se te chega o aviso. Depois volta a pôr o certo.

Sentry dentro do Claude Code

Último passo: ligas o Sentry ao Claude Code com um servidor MCP, para o Claude poder ler os teus erros. No terminal, corre esta linha, com os nomes curtos da tua organização e do teu projeto no Sentry no lugar de TUA-ORG e TEU-PROJETO:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/TUA-ORG/TEU-PROJETO

Na primeira utilização, faz-te iniciar sessão no Sentry pelo navegador; se isso não acontecer, escreve /mcp no Claude Code e escolhe sentry. A ligação só vale no projeto onde correste a linha.

3. Quando dispara o alerta

Quando chega o email ou a notificação, abro o Claude Code no projeto e colo o alerta neste prompt:

Chegou-me este alerta: [cola]. Lê o erro no Sentry e os logs, e escreve-me em cinco linhas: o que se avariou, desde quando, porquê, e a correção que propões. Não mexas em nada em produção até eu te dizer ok.

Cinco linhas porque naquele momento preciso de perceber, não de ler. «Desde quando» diz-me se o último deploy tem alguma coisa a ver. E a última frase é a mais importante: com a app em baixo dá vontade de corrigir logo, e uma correção errada em produção pode fazer mais estragos do que o erro.

4. Se o queres automático

O passo seguinte é nem teres de colar o alerta. Há dois caminhos.

Com uma sessão aberta: /loop

A forma simples: deixas aberta uma sessão do Claude Code, com o Sentry já ligado, e escreves:

/loop 5m vê no Sentry se há erros novos; se houver, lê o stack trace e escreve-me o que se avariou e como o resolverias.

A cada 5 minutos o Claude olha para o Sentry e só te escreve se encontrar erros novos: são cerca de 288 voltas por dia, por isso mantém o prompt curto. Só funciona com a sessão aberta e o computador ligado, e ao fim de 7 dias o loop apaga-se sozinho.

Com o computador desligado: uma rotina com trigger API

Uma rotina na cloud corre mesmo com o computador desligado, mas com horário arranca no máximo uma vez por hora. Para um alerta convém o trigger API: um endereço web que arranca a rotina quando o chamas com o token certo.

Duas coisas a saber antes: as rotinas exigem um plano pago do Claude e ainda estão em pré-visualização, por isso o funcionamento pode mudar.

1. Em claude.ai/code/routines, clica em New routine. O projeto tem de estar no GitHub.
2. Adiciona o Sentry como conector em claude.ai/customize/connectors: a ligação que fizeste com claude mcp add vive no teu computador e a rotina não a vê. Tira os conectores que não fazem falta: durante a rotina o Claude usa-os sem perguntar.
3. Como trigger escolhe API e guarda. Adiciona-se no site, não com /schedule.
4. Copia o endereço da rotina, clica em Generate token e copia logo o token: só o vês uma vez.
5. Na tua ferramenta de avisos, configura uma chamada para esse endereço com o token, com o texto do alerta no campo text.

O limite: o trigger API precisa do token e de headers específicos, que encontras no exemplo ao lado do endereço. As ferramentas de avisos gratuitas podem não conseguir chamá-lo, por isso confirma antes na tua.

O texto do alerta chega à rotina como um dado para ler, não como uma ordem: no prompt tens de ser tu a dizer-lhe para investigar. Eu uso este:

Investiga o alerta descrito no bloco routine-fire-payload. Lê o erro no Sentry, vê os commits recentes e escreve-me em cinco linhas: o que se avariou, desde quando, porquê, e a correção que propões. Não mexas em nada em produção.

A rotina corre sem te pedir permissões, e o resultado encontras na sessão que cria de cada vez que arranca. Por isso «Não mexas em nada em produção» fica: ela investiga e propõe, tu decides.

Os erros mais comuns

• Verificar só a página inicial: pode carregar mesmo com a base de dados parada, por isso põe a verificar /health.
• Uma /health que responde com uma página normal mesmo quando há um erro: faz com que devolva um código de erro.
• Não testar nada: faz disparar o erro de teste e um aviso falso, e vê se te chegam.
• Deixar o Claude corrigir em produção durante o alerta: pede primeiro o diagnóstico e a proposta, depois decides tu.
• Assumir que a rotina vê o Sentry que ligaste no terminal: adiciona-o como conector em claude.ai.

Checklist

• Sentry na app, com o DSN numa variável de ambiente
• Erro de teste chegou ao Sentry
• Página /health que verifica a app e a base de dados
• Monitor a cada 5 minutos em /health, avisos por email e no telemóvel
• Sentry ligado ao Claude Code, sessão iniciada
• Prompt do alerta guardado onde o encontras logo

Perguntas frequentes