Arquitetura

Como monitorar aplicação e servidor pelo WhatsApp (logs, erros e alertas)

WhatsApp é um canal excelente para alerta porque ele tem uma característica que e-mail e dashboard não têm: chega onde você está. O problema é que a maioria das implementações vira bagunça rápido — alerta demais, duplicado, sem contexto, e em pouco tempo todo mundo ignora.

A forma correta de fazer isso é tratar WhatsApp como camada de notificação, não como sistema de monitoramento. Você continua monitorando com ferramentas e sinais confiáveis (uptime, métricas, logs, filas, erros), mas centraliza o envio e a governança dos alertas em um lugar só — e aí o Notifish entra bem.

A ideia é simples: qualquer evento relevante → vira um “evento de notificação” → Notifish entrega no WhatsApp.


O que vale a pena mandar para o WhatsApp (e o que não vale)

WhatsApp deve receber só o que exige ação ou atenção rápida. Em produção, eu separo em três níveis:

Crítico (manda sempre):

  • aplicação fora do ar / endpoint crítico fora
  • erro 5xx em alta (explosão de taxa de erro)
  • fila parou de consumir / backlog crescendo rápido
  • disco quase cheio / risco de indisponibilidade
  • falha em integração crítica (pagamento, mensagens, etc.)

Alerta (manda com filtro):

  • latência acima do normal por X minutos
  • aumento gradual de erros específicos
  • Redis indisponível (com fallback) ou lento
  • uso de CPU/memória alto por período sustentado

Informativo (geralmente não manda no WhatsApp):

  • deploy realizado
  • logs de rotina
  • warnings esporádicos

O que destrói o canal é “alerta informativo demais”. WhatsApp é para sinal forte.


Arquitetura recomendada (sem gambiarra)

O melhor padrão é este:

  1. Você tem fontes de evento (monitoramento/observabilidade):
  • Uptime/health-check (aplicação)
  • Métricas do servidor (CPU, RAM, disco)
  • Logs (erros específicos, padrões)
  • Erros de aplicação (exceptions)
  • Filas (backlog, falhas, retries)
  1. Um “gerador de eventos” cria um evento padronizado.
  2. Você envia esse evento para o Notifish via API.
  3. Você define roteamento, deduplicação e templates
  • para qual número/grupo enviar
  • se deve agrupar, deduplicar, aplicar rate limit
  • qual template usar (curto, completo, escalonamento)

Esse desenho escala porque você não espalha envio de WhatsApp por todo sistema. Você centraliza.


Como fica uma mensagem boa no WhatsApp

Uma mensagem útil precisa ter contexto mínimo e ação sugerida:

  • Título curto (o que aconteceu)
  • Ambiente (prod, staging)
  • Serviço (api, worker, site)
  • Sintoma (erro, timeout, backlog)
  • Impacto (estimado)
  • Link (dashboard/logs, se existir)
  • Ação recomendada (1 linha)

Exemplo de payload humano:

ALERTA CRÍTICO: API 5xx alto
Ambiente: prod | Serviço: api
Erros 5xx: 18% (últimos 5 min)
Endpoint: /api/orders
Ação: verificar logs + dependência “Payments”


Implementação via API com Notifish (modelo prático)

Você pode integrar de dois jeitos:

1) Seu sistema envia eventos diretamente (Laravel, cron, scripts)

Bom quando você mesmo detecta (fila, logs, métricas internas).

2) Ferramentas externas chamam o Notifish (uptime/monitoramento)

Bom para health-check e métricas do servidor (quando a ferramenta já faz o “detector”).

Como você pediu implementação via API, vou te mostrar um modelo que funciona bem

Payload recomendado (evento)

{
"message": "Sua mensagem de alerta",
"identifier": "seu identificador único de disparo",
"link": true,
"typing": "composing",
"delayMessage": 1200
}

Por que esse formato funciona:

  • identifier: chave de deduplicação / idempotência do alerta
  • message: texto já formatado com contexto (ambiente/serviço/ação)
  • delayMessage/typing: ajustes de entrega (opcionais)

Exemplo em Laravel enviando evento ao Notifish

class NotifishClient
{
    public function sendToGroups(string $message, string $identifier, bool $link = true, int $delayMs = 0, string $typing = 'composing'): void
    {
        $url = rtrim(config('services.notifish.base_url'), '/')
            . '/api/v2/' . config('services.notifish.instance')
            . '/whatsapp/message/groups';

        $payload = [
            'message' => $message,
            'identifier' => $identifier,
            'link' => $link,
            'typing' => $typing,
            'delayMessage' => $delayMs,
        ];

        $response = Http::withToken(config('services.notifish.token'))
            ->acceptJson()
            ->contentType('application/json')
            ->timeout(8)
            ->post($url, $payload);

        if (!$response->successful()) {
            logger()->error('Notifish send failed', [
                'status' => $response->status(),
                'body' => $response->body(),
                'identifier' => $identifier,
            ]);
        }
    }
}

Regras importantes para não virar caos

Se você fizer só “manda mensagem”, em 2 semanas o canal morre. Algumas regras que eu considero obrigatórias:

1) Deduplicação

  • Todo alerta precisa de dedupe_key.
  • Se o mesmo alerta acontecer 100 vezes, você manda 1 e “atualiza”/agrupa.

2) Rate limit por severidade

  • Crítico: pode repetir, mas com intervalo mínimo (ex.: 5–10 min).
  • Alerta: intervalo maior (ex.: 15–30 min).
  • Informativo: geralmente fora do WhatsApp.

3) Idempotência

  • Eventos iguais devem produzir o mesmo estado.
  • Se a chamada repetir, não deve disparar em duplicidade.

4) Conteúdo curto
WhatsApp é leitura rápida. Se precisar detalhe, coloque em meta e mande link para logs/dashboard quando possível.

5) Escalonamento
Se continuar crítico por X tempo, notifica outro grupo/gestor.


O que monitorar para disparar eventos úteis (fontes típicas)

Você pode começar com estes gatilhos (são os que mais dão retorno):

  • Health-check HTTP (200/500, tempo de resposta, quedas)
  • Taxa de erro (5xx e exceções por minuto)
  • Fila (backlog, jobs failed, tempo médio)
  • Banco (conexões, queries lentas, timeouts)
  • Redis (latência, indisponibilidade, memória/eviction)
  • Servidor (disco, load alto sustentado)
  • Integrações externas (timeout e falha por janela)

Monitorar “pelo WhatsApp” não é substituir observabilidade por chat. É transformar sinais importantes em alertas acionáveis, com governança. O Notifish entra como a peça que centraliza o envio e impede que cada sistema invente seu próprio jeito de notificar.

Se você faz dedupe, rate limit, severidade e contexto mínimo, o WhatsApp vira um canal confiável — e não um spam de produção.

Leonardo

Engenheiro de Software especializado em PHP e Laravel, com ampla experiência no desenvolvimento de APIs, automações, sistemas de mensageria, estratégias de cache e integrações com serviços externos. Atua na arquitetura e evolução de sistemas escaláveis, com foco em performance, segurança, estabilidade e manutenibilidade do código, aplicando boas práticas de engenharia de software em ambientes de produção críticos.

Recent Posts

Arquitetura de uma API REST em Laravel preparada para produção

Em processos seletivos técnicos, não basta entregar código funcional. Cada vez mais, empresas avaliam arquitetura,…

23 horas ago

Automação de WhatsApp para WordPress: uma solução escalável para empresas e portais

O Notifish é um plugin para WordPress oficialmente aprovado no repositório do WordPress que permite…

2 dias ago

PHP além do CRUD: como escrever código que não vira problema em produção

A maioria dos desenvolvedores PHP sabe fazer CRUD.Isso não te torna pleno. Muito menos sênior.…

3 dias ago

Como identificar um projeto WordPress mal feito em 10 minutos

Você não precisa ser especialista nem passar horas auditando código para saber se um projeto…

4 dias ago

WordPress não é amador. Amador é o uso que fazem dele.

WordPress não é lento, frágil ou amador. Ele só ficou mal-falado porque virou refém de…

5 dias ago

10 inteligências artificiais que você não pode ignorar em 2026

De assistentes que escrevem códigos a geradores de vídeos e músicas em segundos, essas inteligências…

6 dias ago