O que é

O sistema de alertas avisa você quando algo importante acontece no servidor. É a forma de descobrir um problema antes do cliente: CPU no talo, disco cheio, banco caído.

O aviso pode chegar por dois caminhos, cada um com a própria guia em Configurações → Alertas:

• E-mail: vai para o e-mail do administrador;
• Webhook: o servidor envia o alerta para uma URL sua, e uma ferramenta como o n8n repassa para WhatsApp, Telegram, Slack ou o canal que você preferir.

Os dois são independentes: dá para usar só um, os dois, e escolher alertas diferentes em cada um.

O que os alertas cobrem

Marque os que quiser receber, em cada guia:

CPU, memória, disco e banco reenviam no máximo a cada 1 hora; nova versão, a cada 24 horas.

Configurando por e-mail

1. Confirme que o SMTP está configurado e testado.
2. Em Configurações → Alertas, guia E-mail, ligue os alertas desejados.
3. Cada chave salva sozinha.

Configurando por webhook (WhatsApp, Telegram e outros)

O servidor envia cada alerta como um POST em JSON para a URL que você informar. O caminho mais simples é um fluxo no n8n:

1. No n8n, crie um fluxo com o nó Webhook (método POST) e copie a URL de produção dele.
2. Em Configurações → Alertas, guia Webhook, cole a URL e clique em Salvar. O painel gera o secret nessa hora e mostra uma única vez: copie se for conferir a assinatura.
3. No n8n, ligue o Webhook ao nó que envia a mensagem (WhatsApp, Telegram…) e use o campo alert.text como texto: ele já vem pronto, com título, detalhes e o nome do servidor.
4. Publique o fluxo e clique em Enviar teste. O teste funciona mesmo com o envio desativado.
5. Clique em Ativar e ligue os alertas que devem ir para o webhook.

O que chega em cada envio:

• event: o tipo, como alert.cpu, alert.memory, alert.disk, alert.db_down, alert.php_fpm, alert.disk_quota, alert.new_version (e test.ping no teste);
• alert.title, alert.message e alert.text (o texto completo, pronto para repassar);
• server: nome, IP e endereço do painel, para saber de qual servidor veio;
• data: os números do alerta (percentual, GB usados, versões…), para quem quiser montar a própria mensagem.

Segurança:

• a URL não pode apontar para endereço interno (localhost, rede privada, metadados da nuvem): o painel recusa ao salvar e confere de novo a cada envio;
• cada envio leva o header X-GWS-Signature: o HMAC-SHA256 do corpo com o secret. Para ter certeza de que o alerta veio do seu servidor, calcule o mesmo HMAC no n8n e compare;
• o painel não segue redirecionamento. Use a URL final (com https://), senão o envio falha com erro 301.

Entrega: qualquer resposta 2xx conta como entregue. Se falhar, CPU, memória, disco, banco e nova versão tentam de novo no próximo ciclo (5 minutos). A guia mostra o histórico recente de envios, com o status de cada um.

Como interpretar

• CPU alta: o aviso lista o que estava usando a CPU na hora (um site, uma aplicação, uma rotina do servidor como snapshot e backup, ou um serviço), e o principal responsável já aparece no título. Rotina esperada, como o snapshot de madrugada, não é sinal de servidor pequeno; site no topo com frequência é sinal de olhar o tráfego, os crons e os plugins dele.
• Fila alta sem uso real não vira alerta: em servidor pequeno, um pico curto de fila (limpeza de sessões do PHP, um backup começando) passa do limite com a CPU livre. Por isso o painel mede a CPU na hora e só avisa se alguma coisa estiver de fato saturada; o pico que já passou fica só no log do painel. Assim o aviso não te empurra para um upgrade de servidor que você não precisa.
• O título diz a causa e um número que você pode conferir (o uso, que vai no máximo a 100%):
  • CPU cheia: “Uso da CPU em 97% (site X)”, com o principal responsável.
  • Disco: “O servidor está esperando o disco”: quem segura o servidor é o disco, não o processador.
  • Provedor: “O provedor está segurando a CPU deste servidor”: não é consumo dos seus sites, e otimizar o servidor não resolve. Aqui, trocar de plano ou de provedor é a resposta. O corpo do e-mail explica a fila em linguagem simples (quantos programas queriam a CPU ao mesmo tempo): fila não é uso. Se a medição falhar, o aviso sai mesmo assim, pela fila (“Fila da CPU em X% da capacidade”): o painel nunca deixa de avisar por falta de informação.
• Site no teto de CPU: não é um problema do servidor, é o limite funcionando. O site está pedindo mais do que você deu a ele. Vale olhar o que mudou no site antes de simplesmente aumentar o teto.
• CPU/memória altas de forma constante: sinal de que é hora de otimizar os sites (cache) ou fazer upgrade do servidor. Comum ao adicionar muitos sites.
• Banco offline: raro no GW Server (há proteções contra isso), mas o alerta existe por garantia. Acontecia com frequência no WordOps em picos de 100% de CPU.
• Cota de clientes: o painel avisa (administrador e usuário), mas por padrão não derruba a aplicação do cliente, para não interromper um trabalho no meio.

Veja também

• E-mail e SMTP do painel
• Limites de CPU
• Uso de recursos e disco
• Monitor e auto-recuperação do PHP-FPM