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)

2. Um “gerador de eventos” cria um evento padronizado.
3. Você envia esse evento para o Notifish via API.
4. 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.

The post Como monitorar aplicação e servidor pelo WhatsApp (logs, erros e alertas) appeared first on Leonardo Nascimento | Engenheiro de Software.

Monitorar bem não é coletar o máximo de dados possível. É escolher, com critério, aquilo que realmente indica a saúde do sistema e permite agir antes que o impacto se torne maior.

O primeiro ponto que merece atenção é a disponibilidade real. Não no sentido abstrato de “o servidor está ligado”, mas se o sistema está efetivamente acessível para quem depende dele. Uma aplicação pode estar no ar e, ainda assim, indisponível do ponto de vista do usuário. Monitorar endpoints críticos, fluxos principais e páginas essenciais costuma ser mais valioso do que observar métricas genéricas de infraestrutura isoladamente.

Disponibilidade, no entanto, não conta a história inteira. Muitos problemas começam de forma silenciosa, como uma degradação progressiva de desempenho. Um sistema que responde lentamente por alguns minutos ou horas já está falhando, mesmo sem cair completamente. Acompanhar latência ao longo do tempo ajuda a identificar gargalos antes que eles se tornem incidentes graves, além de revelar dependências externas que começam a responder de forma instável.

Outro ponto frequentemente subestimado é o comportamento dos erros. Todo sistema apresenta falhas ocasionais, e isso é esperado. O problema não está no erro isolado, mas na repetição, no padrão e na concentração. Quando uma mesma falha começa a ocorrer com frequência crescente, ela deixa de ser exceção e passa a ser sinal de degradação. Monitoramento eficiente olha para tendências, não apenas para eventos pontuais.

Logs entram exatamente nesse contexto. Em produção, logs não servem para registrar tudo, mas para permitir reconstruir o que aconteceu quando algo dá errado. Logs bem pensados ajudam a responder perguntas simples com rapidez: qual fluxo foi afetado, em que momento, com quais dados e sob quais condições. Quando isso não é possível, o tempo de investigação cresce e a confiança no sistema diminui.

Nenhum sistema moderno funciona isoladamente, e por isso dependências externas precisam fazer parte do monitoramento. APIs de terceiros, serviços de mensageria, gateways de pagamento e qualquer recurso externo podem se tornar gargalos ou pontos únicos de falha. Ignorar essas dependências costuma levar a diagnósticos errados, onde o time tenta corrigir um problema interno que, na verdade, começou fora do sistema.

Alertas, por sua vez, exigem ainda mais cuidado. Um alerta só faz sentido se houver alguém responsável por ele e se a ação esperada estiver clara. Alertas em excesso criam ruído, e ruído gera descrédito. Com o tempo, ninguém reage mais. Um bom sistema de alertas dispara pouco, mas quando dispara, exige atenção imediata. Confiabilidade aqui é mais importante do que cobertura total.

Com a evolução do sistema, o monitoramento também precisa evoluir. Fluxos mudam, riscos novos surgem, padrões antigos deixam de ser relevantes. Métricas e alertas que não são revisados acabam perdendo valor e permanecem ativos apenas por inércia. Monitoramento eficaz é um processo contínuo, não uma configuração feita uma única vez.

Vale deixar claro que monitoramento não corrige arquitetura ruim. Ele ajuda a enxergar problemas, não a resolvê-los. Sistemas mal desenhados tendem a gerar alertas constantes, comportamento imprevisível e alto custo operacional. Quando a base é sólida, o monitoramento se torna uma ferramenta de apoio, não uma tentativa de contenção.

No fim, o que realmente vale a pena acompanhar é aquilo que afeta diretamente a operação: disponibilidade percebida, tempo de resposta, comportamento de erros, saúde das dependências externas e padrões anormais de uso. O restante deve existir apenas se contribuir para decisões melhores.

Monitorar sistemas não é uma disputa por quem coleta mais métricas, mas por quem reage melhor aos sinais certos. Quando bem feito, o monitoramento reduz impacto, antecipa problemas e traz previsibilidade à operação. Esse tipo de maturidade técnica raramente aparece por acaso — ela nasce da experiência de quem já lidou com produção de verdade.

The post Monitoramento e alertas: o que realmente vale a pena acompanhar appeared first on Leonardo Nascimento | Engenheiro de Software.

Através de uma interface simples e agradável, é possível monitorar múltiplos sites , com intervalos de tempo entre 15 segundos e 1 hora, selecionar até 8 localizações,  com tempo mínimo de resposta entre 0.125 e 2.0 segundos e “callbacks” (SMS, Telegram, Slack, StatusPage, Zapier) para ser informado em caso de queda ou restauração do serviço.

Desenvolvi a estratégia para um amigo, que gostaria de receber alertas no WhatsApp em tempo real, quando algum site ou sistema fica-se fora do ar, decidimos tornar o código fonte público.

Requerimentos

• Wppconnect Server
• PHP 7.4

O Wppconnect Server é uma lib não oficial do WhatsApp para envio e recebimento de mensagens. para receber a notificação em seu WhatsApp é necessário ter configurado o Wppconnect server.

Neste tutorial, aprenderemos a configurar o Updown Notify WhatsApp

Updown Notify Whatsapp

Clone o projeto e acesse o diretório

git clone https://github.com/leonardop21/updown-notify-whatsapp && cd updown-notify-whatsapp

Instale as dependências (Necessário ter o composer configurado na máquina)

composer install

Configurando o projeto

No arquivo /public/callback configure um chave pública, ex: Afwe14we555d1230we23sdx

No arquivo /services/WppInfo na função __construct() preencha os dados gerados no Wppconnect-server, para receber notificações no WhatsApp

Apontando para a pasta public

Configure seu servidor http, para ler a partir da pasta public.

Agora, no sistema do Updown.io

No Updown.io insira a sua url de callback junto com a key que definiu, ex: https://meusite.com.br/callback?key=Afwe14we555d1230we23sdx

O Updown Notify Whatsapp aceita apenas requisições post com a key configurada no passo anterior, do contrário, uma página 404 será exibida.

Testando a aplicação

Criei um subdomínio de teste e inseri no updown.io.

No momento em que o site ficou fora do ar, recebi um aviso no WhatsApp, quando voltou ao normal, recebi outro aviso, conforme demonstra as imagens abaixo.

Updown detectou site fora do ar

Callback Updown

O Updown enviou um callback ao sistema, que por sua vez acionou o Wppconnect-Server enviando uma mensagem para o número configurado no services/WppInfo

Site funcionando normalmente

Updown detectou que o site voltou a funcionar

Callback Updown

O Updown enviou um callback ao sistema, que por sua vez acionou o Wppconnect-Server enviando uma mensagem para o número configurado no services/WppInfo

Links úteis

WPPCONNECT-SERVER

UPDOWN-NOFITY-WHATSAPP

The post UPDOWN.IO: Receba notificação no WhatsApp caso seu site fique indisponível appeared first on Leonardo Nascimento | Engenheiro de Software.