Monitore servidores com n8n

O que é e por que usar

Monitorar servidores é uma daquelas tarefas que ninguém quer fazer manualmente, mas que pode custar caro quando negligenciada. Um servidor fora do ar por 30 minutos em horário comercial pode significar dezenas de clientes insatisfeitos, vendas perdidas e horas de retrabalho para a equipe técnica. Ferramentas tradicionais como Zabbix, Nagios ou Datadog resolvem o problema, mas trazem complexidade própria: infraestrutura para hospedar, configuração de agentes, licenças e uma curva de aprendizado que espanta times pequenos.

O n8n oferece uma alternativa intermediária. Como plataforma de automação de código aberto, ele pode ser configurado para executar verificações periódicas em seus servidores — seja via ping HTTP, SSH, consulta a APIs de métricas ou até mesmo verificando portas específicas — e reagir automaticamente a qualquer anomalia. A lógica de monitoramento é montada visualmente, com nós que se conectam, e o custo é apenas o da infraestrutura onde o próprio n8n já roda.

Outra vantagem prática: como o n8n já possui integrações nativas com mais de 400 serviços (Slack, Telegram, Gmail, PagerDuty, entre outros), o alerta de falha não precisa parar em um e-mail que ninguém lê. Ele pode acionar um chamado no seu sistema de tickets, enviar uma mensagem no grupo de plantão ou até executar um webhook para reiniciar um serviço automaticamente. Neste artigo, você vai montar um monitor completo, do zero, com passos claros e sem enrolação.

Pré-requisitos

Para acompanhar o passo a passo, você vai precisar de:

• Uma instância do n8n rodando — pode ser self-hosted (via Docker ou npm), na nuvem ou no plano cloud oficial. Qualquer versão a partir da 1.0 funciona.
• Acesso a um servidor para monitorar — pode ser um VPS da DigitalOcean, AWS EC2, um servidor Linux local ou até um endpoint HTTP simples.
• Conhecimento básico de HTTP — entender o que são códigos de resposta (200, 404, 500) e como um request GET funciona é suficiente.
• Um canal para receber alertas — recomendo um webhook do Slack ou um bot do Telegram. Ambos são gratuitos. Se não tiver nenhum, um e-mail via SMTP também serve.
• Credenciais de acesso — se for monitorar por SSH, tenha a chave privada ou senha do servidor. Se for via API, já tenha o token de autenticação em mãos.

Se você nunca usou o n8n, gaste 20 minutos explorando a interface antes de começar. Crie um workflow simples com dois nós conectados para se acostumar com o conceito de trigger (gatilho) e action (ação). O conhecimento necessário é esse: um nó inicia o fluxo e os demais executam tarefas em sequência.

Exemplo Prático: alerta automático quando um site fica fora do ar

Cenário real: imagine que você trabalha em uma agência digital que mantém sites de 12 clientes em diferentes servidores. Antes do n8n, o processo era manual: um developer acessava cada URL às 8h da manhã, conferia se abria, e torcia para nada quebrar durante o dia. Quando um servidor caía às 3h da manhã, o problema só era notado no dia seguinte, com dezenas de reclamações acumuladas.

O que será automatizado: um workflow do n8n que, a cada 5 minutos, faz uma requisição HTTP para a URL do site principal. Se o retorno for diferente de 200 (OK), o workflow envia uma mensagem imediata para o Slack do time com o número do erro e o horário exato. Se o site voltar ao normal em uma nova verificação, uma segunda mensagem avisa que o serviço foi restaurado.

Resultado esperado: o tempo de detecção de uma falha cai de horas para no máximo 5 minutos. O time recebe o alerta no celular, mesmo fora do expediente, e pode agir antes que o cliente perceba o problema. A segunda mensagem (recuperação) evita que técnicos fiquem checando o status manualmente depois que resolvem o incidente.

Configuração Passo a Passo

Vamos montar o workflow do zero. No n8n, cada componente do fluxo é um nó. Você vai usar quatro nós: um de agendamento, um de requisição HTTP, um de condição e um de notificação no Slack.

Passo 1 — Criar o workflow e adicionar o trigger de agendamento

No painel do n8n, clique em “New workflow” e dê um nome como “Monitor de Servidor — Site Cliente A”. No painel de nós, adicione um nó do tipo Schedule Trigger.

• Em Rule Type, selecione “Custom” ou “Interval” e configure para executar a cada 5 minutos.
• Se preferir horário comercial, use a opção de cron: */5 * * * * executa a cada 5 minutos durante o dia, todos os dias.

Esse é o coração do monitor. A partir dele, o n8n vai disparar o fluxo indefinidamente, até que você desative o workflow.

Passo 2 — Adicionar o nó de requisição HTTP

Arraste o nó HTTP Request e conecte-o à saída do Schedule Trigger. As configurações principais são:

• Method: GET
• URL: aponta para o endereço que você quer monitorar. Exemplo: https://www.seucliente.com.br (adicione http:// se o site não tiver SSL).
• Options: ative a opção para não seguir redirecionamentos automaticamente ou permita, conforme sua necessidade. Na dúvida, deixe o padrão.
• Timeout: defina 10 segundos. Se o servidor não responder nesse intervalo, o nó retorna erro — exatamente o que queremos capturar.

Configure também a autenticação se a URL exigir. Em Credential for HTTP Request, adicione o tipo apropriado (Basic Auth, Header ou Query). Para a maioria dos sites públicos, não será necessário.

Passo 3 — Criar o nó de condição (IF)

Adicione um nó IF e conecte na saída do HTTP Request. Esse nó vai separar os dois caminhos possíveis: sucesso ou falha.

• Condition: Número > < / > =
• Value 1: {{ $json.statusCode }} — esse é o código HTTP retornado.
• Operation selecione “Not Equal”.
• Value 2: 200

Traduzindo: se o status code for diferente de 200, o fluxo segue pelo ramo “true” (falha). Se for 200, segue pelo ramo “false” (tudo ok). Importante: o n8n retorna o JSON da resposta no nó HTTP Request. Exemplo do formato de saída:

{
  "statusCode": 200,
  "headers": {
    "content-type": "text/html; charset=UTF-8",
    "server": "nginx"
  },
  "body": "<html>...</html>"
}

Passo 4 — Configurar o alerta de falha no Slack

Na saída “true” do nó IF, adicione um nó Slack.

• Escolha a operação “Send message”.
• Selecione o canal do time (ex: #infra-alertas).
• No campo de texto, insira uma mensagem com informações úteis para o plantão:

🚨 ALERTA: O site https://www.seucliente.com.br está fora do ar!
Código HTTP: {{ $json.statusCode }}
Horário: {{ $now }}
Verificação: a cada 5 minutos.
Ação necessária: verificar o servidor AGORA.

Se você usa Telegram, o processo é idêntico: troque o nó Slack pelo nó Telegram e informe o chat ID. Se não usa nenhum dos dois, a alternativa mais simples é um nó Email com o protocolo SMTP do Gmail ou do seu provedor.

Passo 5 — Configurar o alerta de restauração

Aqui está um detalhe que muitos tutoriais ignoram: alertar apenas na falha gera um acúmulo de mensagens enquanto o site está fora. A cada 5 minutos, o time recebe uma nova mensagem de erro — um ruído inútil. A solução é usar o nó IF em um segundo fluxo, mas com uma condição diferente, ou simplesmente usar uma variável de estado.

A abordagem mais elegante no n8n é criar uma segunda saída no mesmo IF e tratar a “recuperação” ali. Na saída “false” do nó IF (site respondeu 200), acrescente outro nó Slack com uma mensagem de que o serviço está normalizando. Para evitar notificação a cada 5 minutos mesmo quando o site sempre esteve ok, você restringe o alerta usando o histórico do nó ou um webhook de “lastDownTime”. Na prática, para a maioria dos casos, envie a mensagem de recuperação apenas se o status anterior foi de falha — isso pode ser feito consultando um nó de banco de dados ou usando um arquivo de estado em um nó “Code”.

Exemplo de lógica em um nó Code colocado antes do Slack de recuperação:

// Verifica se a última checagem também foi 200.
// Se sim, não envia nada. Se foi falha, envia alerta de volta.
const lastStatus = $getWorkflowStaticData('global').lastStatus;
const currentStatus = $json.statusCode;

if (currentStatus === 200 && lastStatus !== 200) {
  $getWorkflowStaticData('global').lastStatus = 200;
  return [{ alert: 'restored', message: 'Serviço restaurado.' }];
}

$getWorkflowStaticData('global').lastStatus = currentStatus;
return [{ alert: 'noop' }];

Essa lógica usa o Workflow Static Data do n8n para guardar o último status entre execuções. A saída do nó Code será vazia quando não houver transição de estado; o alerta só dispara na mudança falha → ok.

Passo 6 — Testar e ativar o workflow

Com todos os nós conectados, clique em Execute Workflow para rodar uma vez. Verifique no painel de execução se o nó HTTP Request retornou 200. Depois, para testar a falha, use uma URL inexistente ou um site que você sabe que está fora do ar. Confirme se a mensagem do Slack chega. Por fim, clique em Active no canto superior direito para ativar o workflow em produção. Pronto — seu monitor está rodando.

Dicas e Variações

O monitor básico cobre o caso mais comum, mas o mesmo esqueleto serve para cenários bem mais avançados. Vale estudar estas variações:

• Monitore múltiplos servidores em um único workflow: ao invés de criar um workflow por cliente, use um nó Spreadsheet ou JSON como origem de dados. O nó HTTP Request pode ser colocado em loop com um nó Split In Batches, fazendo a verificação de cada URL da lista.
• Adicione métricas de desempenho: o nó HTTP Request coleta apenas o status code. Para medir tempo de resposta, use um nó Code após a requisição, calculando a diferença entre Date.now() antes e depois.
• Monitore portas específicas: nem tudo é HTTP. Para verificar se uma porta TCP está aberta (ex: 3306 para MySQL), use o nó TCP nativo do n8n ou um nó Exec com o comando nc -zv host porta.
• Integração com PagerDuty ou Opsgenie: para times maiores, o alerta no Slack não é suficiente — precisa virar um incidente formal. Use o nó de webhook para chamar a API da sua ferramenta de incidentes. Com isso, você ganha escalonamento automático.
• Use e-mail do n8n como fallback: se Slack e Telegram caírem (improvável, mas possível), o alerta precisa chegar de alguma forma. Configure um nó de e-mail paralelo na saída de falha, usando um provedor SMTP. Duplicar o caminho de alerta custa pouco e evita cegueira total.

Erros Comuns e Como Evitá-los

Durante testes e produção, a maioria dos problemas de monitoramento no n8n se encaixa em cinco categorias. Conhecê-las antecipadamente economiza horas de debugging:

• A webhook do Slack não envia mensagem: na maioria dos casos é o token com permissão errada ou o canal com o bot não adicionado. Verifique se o app do Slack está instalado no workspace e se o bot foi convidado para o canal com /invite @nome-do-bot. Teste o webhook isoladamente no nó antes de conectar todo o fluxo.
• Checangens com timeout muito curto: definir 3 segundos pode gerar falsos positivos em servidores lentos. Antes de ativar o monitor, meça o tempo médio de resposta do site com uma ferramenta simples e adicione uma margem de 50%. Se o site costuma responder em 4 segundos, o timeout deve ser de pelo menos 8 segundos.
• Ignorar o status de redirecionamento: sites que usam HTTP → HTTPS geram um código 301 ou 302 na primeira chamada. Se o nó IF considera apenas o 200, a condição “not equal” vai disparar falso alerta. Configure o HTTP Request para seguir redirecionamentos (a opção Follow Redirect) e o status final será 200.
• Esquecer permissões no servidor: se o monitor usa SSH para verificar espaço em disco ou uso de CPU, o usuário configurado precisa das permissões adequadas. Erros de permissão aparecem na execução do nó como mensagens genéricas tipo “Connection refused”. Sempre crie um usuário específico no servidor para essa finalidade, sem privilégios de root.
• Overload de mensagens em falhas prolongadas: já tratamos isso, mas vale repetir: um site fora do ar por 3 horas gera 36 mensagens de alerta (a cada 5 minutos). O time acaba silenciando o canal. Use a lógica de estado com o nó Code, conforme mostrado no Passo 5, para enviar apenas o primeiro alerta e o alerta de recuperação. Isso mantém o canal limpo e o alerta efetivo.

Próximos Passos

O workflow que você montou hoje já resolve o problema de “site fora do ar sem aviso”, mas isso é apenas a superfície do que o n8n pode fazer por sua infraestrutura. Defina a sua próxima ação em três frentes:

1. Expanda o monitoramento para recursos do servidor: crie um segundo workflow que, a cada hora, se conecta ao servidor via SSH e executa df -h (espaço em disco) e free -m (memória). Configure alertas para uso acima de 85% de disco. Isso previne a maioria dos incidentes de indisponibilidade causados por falta de espaço.
2. Adicione um dashboard simples: use o nó Spreadsheet para gravar o resultado de cada verificação (horário, status, tempo de resposta) em uma planilha do Google Sheets. Em uma semana, você terá um histórico para mostrar tendências e justificar upgrades de infraestrutura com dados reais.
3. Automatize a