Sumário
- Por que notificações push falham em serviços críticos
- Como funcionam os alertas por chamada com o Echobell
- Configurando alertas por chamada na sua ferramenta de monitoramento
- Usando sua verificação de integridade existente
- O que incluir no alerta
- Escolhendo o nível de urgência certo
- Escalando para vários serviços
- O benefício real
- Relacionados
Sua API cair às 3 da manhã não é o problema. O problema é descobrir isso às 9 da manhã, quando seus usuários já lotaram a caixa de entrada do suporte.
A maioria das ferramentas de monitoramento é ótima em detectar falhas. Elas são péssimas em garantir que alguém realmente veja o alerta na hora certa. Uma notificação push comum fica parada na tela bloqueada até alguém pegar o celular por acaso. Uma mensagem no Slack some em um canal que ninguém acompanha de madrugada. Um e-mail fica sem ser lido até a manhã de segunda-feira.
Alertas por chamada telefônica mudam essa equação. Quando a verificação de integridade da sua API falha, seu celular toca de verdade — do mesmo jeito que tocaria para qualquer outro assunto urgente. Você atende, ouve o que está errado e pode começar a resolver na hora, em vez de horas depois.
Por que notificações push falham em serviços críticos
Um smartphone comum recebe de 50 a 100 notificações push por dia. O alerta de falha da sua API concorre com atualizações de aplicativos, notificações de redes sociais, alertas de notícias e todos os outros apps do aparelho. Quando tudo é urgente, nada parece urgente.
Isso cria um padrão perigoso:
- Sua ferramenta de monitoramento detecta que a API está retornando erros 500
- Ela envia uma notificação push para o seu celular
- Seu celular está sobre a mesa, virado para baixo, com o modo Foco ativado
- O alerta fica ali em silêncio até alguém perceber — horas depois
Para um microsserviço não crítico, esse atraso é chato. Para uma API de pagamentos, um serviço de autenticação ou o backend do seu produto principal, esse atraso custa dinheiro e confiança de verdade.
Como funcionam os alertas por chamada com o Echobell
O Echobell entrega notificações em três níveis de urgência:
- Normal: notificação push comum
- Urgente: atravessa o modo Foco do iOS, mas não toca
- Chamada: faz seu celular tocar como uma ligação telefônica comum
Para falhas de API que afetam usuários, o nível de chamada é o mais adequado. Ele reproduz a forma como você lidaria com qualquer outra ligação urgente — você atende porque o telefone está tocando.
A configuração é simples:
- Crie um canal no Echobell
- Defina o tipo de notificação como Chamada
- Conecte sua ferramenta de monitoramento via webhook
- Quando a verificação de integridade falhar, o Echobell liga para o seu celular
Configurando alertas por chamada na sua ferramenta de monitoramento
A maioria das plataformas de monitoramento consegue enviar um webhook quando uma verificação falha. Veja como ligar as pontas.
Usando sua verificação de integridade existente
Se você já tem um endpoint de saúde (como /health ou /status), configure seu monitor para verificá-lo em intervalos regulares. Quando a resposta não for 200, acione o webhook.
O Echobell aceita payloads de webhook com título e corpo:
curl -X POST https://hook.echobell.one/t/<channel-token> \
-H "Content-Type: application/json" \
-d '{
"title": "API FORA DO AR: payment-service",
"body": "Verificação de integridade falhou - erro 500 às 03:42 UTC",
"notificationType": "calling",
"externalLink": "https://your-dashboard.example.com/incidents/123"
}'O campo notificationType: calling é o que faz o celular tocar.
O que incluir no alerta
Mantenha o conteúdo do alerta fácil de ler rapidamente. Quando você atende uma ligação às 3 da manhã, precisa entender o problema na hora:
- Nome do serviço — qual API ou microsserviço falhou
- Tipo de erro — timeout, 5xx, conexão recusada
- Horário — quando a falha começou
- Link — onde investigar imediatamente
Este não é o lugar para mensagens prolixas. O objetivo é ter contexto imediato para decidir se você acorda de vez ou apenas confirma o alerta e volta a dormir.
Escolhendo o nível de urgência certo
Nem toda falha de API precisa de uma ligação. Use alertas em chamada para:
- Serviços de pagamento e cobrança
- Endpoints de autenticação e login
- APIs do produto principal com as quais os usuários interagem diretamente
- Serviços dos quais outros sistemas críticos dependem
Use notificações urgentes para:
- Serviços secundários que são importantes, mas não críticos para a receita
- Ambientes de desenvolvimento ou de staging
- Sinais de alerta (taxas de erro altas que ainda não são falhas completas)
Use notificações normais para:
- Tarefas em segundo plano não críticas
- Métricas informativas que não exigem ação
Essa abordagem gradual mantém você avisado sem gerar fadiga de alertas.
Escalando para vários serviços
Se você mantém mais de uma API, crie canais separados para cada serviço ou grupo de serviços:
production-payment-api— nível de chamadaproduction-user-api— nível de chamadaproduction-analytics-api— urgentestaging-all— urgente
Isso permite ajustar a urgência por serviço. Sua API de pagamentos merece uma ligação; seu pipeline de analytics provavelmente não.
O benefício real
O valor dos alertas por chamada telefônica não está no toque em si. Está na mudança de comportamento que ele provoca:
- Você resolve problemas mais rápido porque fica sabendo deles imediatamente
- Você dorme melhor sabendo que, se algo quebrar, você realmente vai ser acordado
- Seus usuários enfrentam menos tempo de indisponibilidade porque você responde em minutos, e não em horas
Para serviços críticos, essa diferença é justamente o ponto.