Sumário
O perigo de um cron job que falha é que nada acontece. Nenhuma página de erro, nenhum crash, nenhum usuário irritado — apenas um backup que parou de rodar silenciosamente três semanas atrás, um relatório que nunca foi enviado ou um script de limpeza que deixou um disco encher até a produção cair.
O cron em si não tem nenhum alerta embutido. Se um job termina com erro, o cron dá de ombros. Se o servidor inteiro estiver fora do ar no horário agendado, o job simplesmente nunca roda, e não sobra nada para avisar você disso. É esse segundo caso que a maioria das configurações de monitoramento deixa passar.
Este guia apresenta três padrões para pegar os dois tipos de falha e mostra como tornar o alerta impossível de ignorar, escalando-o para uma ligação de verdade com o Echobell.
Padrão 1: alerta de falha com um hook de código de saída
A abordagem mais simples: disparar um webhook sempre que o job terminar com status diferente de zero.
Primeiro, crie um canal no Echobell e copie a URL do webhook dele. Depois, envolva seu comando cron:
0 3 * * * /opt/scripts/backup.sh || curl -s "https://hook.echobell.one/t/<channel-token>?title=Backup+failed&host=$(hostname)"Se o backup.sh funcionar, nada acontece. Se falhar, o Echobell entrega um alerta no seu celular em segundos. Os parâmetros de query viram variáveis de modelo, então sua notificação pode dizer exatamente qual host e qual job falhou.
Para scripts mais longos, um trap dá um contexto mais rico:
#!/usr/bin/env bash
set -euo pipefail
notify_failure() {
curl -s -X POST "https://hook.echobell.one/t/<channel-token>" \
-H "Content-Type: application/json" \
-d "{\"job\":\"nightly-backup\",\"host\":\"$(hostname)\",\"line\":\"$1\"}"
}
trap 'notify_failure $LINENO' ERR
# ... a lógica do seu job ...A limitação: isso só funciona quando o script realmente roda e falha. Se o servidor estiver fora do ar, se o cron estiver mal configurado ou se alguém comentou a linha durante uma sessão de depuração, nenhum alerta é disparado. É por isso que você também vai querer o padrão 2.
Padrão 2: dead man's switch para execuções perdidas
Um dead man's switch inverte a lógica: o job envia um ping para um monitor quando tem sucesso, e o monitor avisa você quando o ping não chega no horário previsto. Isso pega todos os modos de falha — erros, travamentos, servidores mortos e entradas de crontab apagadas.
Duas opções populares que você mesmo pode hospedar funcionam bem com o Echobell:
- Healthchecks.io foi feito exatamente para isso. Crie um check com o seu agendamento cron e um período de tolerância, depois adicione
&& curl -s https://hc-ping.com/YOUR_UUIDao final da sua linha do cron. Quando um ping atrasa, o Healthchecks envia um webhook — aponte-o para o seu canal do Echobell e um backup perdido vira um celular tocando. - Uptime Kuma tem um tipo de monitor "Push" que funciona da mesma forma: seu job chama uma URL de push e o Uptime Kuma dispara alertas pelas integrações de notificação dele quando o heartbeat para de chegar.
Nos dois casos, o fluxo é: cron job → ping de sucesso → monitor percebe o silêncio → webhook para o Echobell → notificação push ou ligação.
Padrão 3: verificações por janela de tempo para jobs que reportam dados
Alguns jobs são mais bem verificados pela saída do que pelo código de saída. Se o seu ETL noturno deve inserir linhas até as 4h, um pequeno job de verificação pode conferir a contagem de linhas e chamar o webhook do Echobell quando os números não baterem.
As condições do Echobell ajudam aqui: você pode enviar um webhook de status depois de cada execução e deixar o canal decidir quando notificar. Uma condição como status != "ok" mantém as execuções bem-sucedidas em silêncio, e as variáveis de tempo UTC embutidas permitem restringir os alertas à janela em que o job deveria ter terminado.
Como tornar o alerta impossível de ignorar
Detectar é só metade do problema. Um alerta de falha de backup que chega como um banner silencioso às 3h da manhã é, na prática, igual a nenhum alerta.
No Echobell, cada canal escolhe um nível de urgência:
- Normal — uma notificação push comum, boa para jobs informativos
- Urgente — atravessa o modo Foco do iOS, ideal para jobs que alguém deveria olhar logo
- Chamada — seu celular toca como uma ligação de verdade até você perceber
Para jobs em que uma falha silenciosa custa dinheiro de verdade — backups de banco de dados, execuções de faturamento, renovações de certificado — configure o canal como Chamada. A diferença entre "vi às 3h" e "vi às 9h" é exatamente a diferença que um alerta por ligação faz.
Se várias pessoas dividem a responsabilidade por um job, compartilhe o link de inscrição do canal com o time; todo mundo que se inscrever recebe o mesmo alerta no mesmo instante.
Qual padrão você deve usar?
- Hook de código de saída: cinco minutos para configurar, pega falhas explícitas. Comece por aqui.
- Dead man's switch: pega também execuções perdidas e travadas. Use em todo job cuja falha você realmente sentiria.
- Verificações de dados por janela de tempo: para pipelines em que "rodou com sucesso, mas produziu lixo" é um risco real.
Eles se combinam bem: o hook de código de saída diz que um job falhou e por quê, enquanto o dead man's switch garante que você fique sabendo das falhas que nunca tiveram a chance de se anunciar.
Configure seu primeiro alerta de cron em poucos minutos: baixe o Echobell, crie um canal e adicione um curl à sua crontab. Da próxima vez que um job agendado morrer às 3h da manhã, seu celular vai tocar — e o backup que você for restaurar no próximo trimestre vai existir.