---
title: "Alertas de falha em cron jobs: receba uma ligação quando um job agendado morre"
description: "Cron jobs falham em silêncio. Conheça três padrões confiáveis para detectar jobs agendados que falharam ou nunca rodaram e receber uma notificação push ou uma ligação em segundos."
date: 2026-07-16
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - cron jobs
  - alertas de falha
  - alertas por ligação
  - monitoramento
  - webhook
---

# Alertas de falha em cron jobs: receba uma ligação quando um job agendado morre

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](/pt).

## 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:

```bash
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](/pt/docs/template), 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:

```bash
#!/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](https://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_UUID` ao 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](/pt/docs/developer/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](/pt/docs/conditions) 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](/pt/features/call-notifications) 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](/pt), 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.