O modo de falha que ninguém fala: uma tarefa agendada para de executar e nada te avisa. Windows Task Scheduler mostra status verde “Pronto” enquanto o script subjacente sai silenciosamente por uma dependência faltante há três semanas. Um job cron no servidor doméstico sobrevive a uma atualização do SO no cronograma mas não no ambiente, e o backup que deveria executar toda noite para de escrever arquivos. O sistema não acha que nada está errado porque nada foi lançado. O backup simplesmente desapareceu.
Testamos 7 melhores aplicativos para detectar falhas silenciosas de tarefas agendadas em Linux, Windows e macOS em 2026. A lista cobre os serviços dead-man-switch que esperam um ping do seu job e alertam quando fica silencioso, os monitores de uptime gerais que também lidam com heartbeats em modo push, os exportadores de métricas que deixam você representar o padrão em gráfico, e as ferramentas locais que transformam o sinal bruto em um alerta onde você realmente lê.
O que procurar em um monitor de tarefas agendadas
Escolha uma ferramenta que:
- Use um dead-man switch, não só “verifica se o código de saída era zero.” O ponto é que o job não está rodando em absoluto.
- Lida com tolerância de cronograma sensatamente. Um job que executa às 03:00 deveria tolerar alguns minutos de desvio antes de alertar; um job que executa a cada minuto não deveria tolerar horas.
- Envia alertas para um canal que você verifica. Email é bom até o apagão estar no seu servidor de e-mail; sobreponha pelo menos um canal não-email (um serviço push, um webhook Discord, um SMS).
- Roda independentemente do host que monitora. Um monitor que morre com a caixa que vigia não é um monitor.
- Não requer pagamento por job. Casas costumam ter vinte ou trinta tarefas agendadas; um modelo de cobrança por job transforma infraestrutura doméstica em um centro de custos corporativo.
Comparação rápida
| Aplicativo | Melhor para | Abordagem | Self-hosted | Nível gratuito |
|---|---|---|---|---|
| Healthchecks.io | Dead-man switch com opção self-hosted | Push heartbeat | Sim | Sim, 20 checagens |
| Cronitor | Telemetria cron completa com estatísticas por job | Push + wrapper | Não | Sim, 5 monitores |
| Dead Man’s Snitch | O serviço de heartbeat de tarefa agendada original | Push heartbeat | Não | Sim, 1 snitch |
| Uptime Kuma | Monitor de uptime self-hosted com modo push | Pull + push | Sim | Grátis, self-hosted |
| Prometheus Node Exporter | Métricas para status de systemd timer | Pull métricas | Sim | Grátis |
| systemd | Detecção nativa de falhas no Linux | Nativa | Sim | Grátis |
| Gotify | Servidor de notificação push self-hosted | Push server | Sim | Grátis |
Por que “a tarefa executou” não é a mesma coisa que “a tarefa funcionou”
O modelo mental que a maioria dos agendadores usa é “o processo terminou?” e o modelo mental necessário é “o resultado aconteceu?” Um script de backup que terminou com sucesso porque o diretório de origem estava vazio não é um backup que funciona. Uma sincronização que terminou com sucesso porque a rede estava offline e o loop de retry desistiu silenciosamente não é uma sincronização que funciona. Uma tarefa rebuild-search-index que terminou com sucesso porque o daemon estava down e o cliente retornou uma resposta vazia não é uma reconstrução que funciona.
A correção tem duas camadas: o job envia um heartbeat só depois de ter feito seu trabalho real (não apenas depois de ter começado), e o monitor alerta quando o heartbeat desaparece. Nada mais na pilha de cronograma detecta o modo “silenciosamente não fazendo nada”. Task Scheduler não vai. Cron não vai. Windows Event Log não vai.
Os aplicativos
1. Healthchecks.io — melhor dead-man switch com opção self-hosted
Healthchecks.io é a implementação de referência do padrão dead-man-switch. Cada tarefa agendada recebe uma URL única, o job faz curl nessa URL no final de sua execução bem-sucedida, e Healthchecks alerta se o ping não chegar na janela esperada. Períodos de graça por checagem, ping-with-exit-code (assim curl $URL/fail marca explicitamente a checagem como falhada), e cronogramas por checagem expressos como um intervalo simples ou uma expressão cron completa. Slack, Discord, PagerDuty, Gotify, ntfy, email, SMS, webhook, e cerca de vinte outros canais de alerta.
Onde fica aquém: O nível gratuito hospedado se limita a 20 checagens; casas com grandes superfícies de automação vão superar isso. Self-hosting corrige isso mas adiciona um serviço para manter.
Plataformas: Qualquer host Linux/Docker para self-hosted. O nível hospedado funciona de qualquer coisa que possa fazer uma requisição HTTP.
Baixar: Healthchecks.io install
Conclusão: O padrão correto para heartbeats de tarefas agendadas em um servidor doméstico.
2. Cronitor — melhor telemetria cron completa com estatísticas por job
Cronitor vai além do heartbeat e captura a imagem de runtime completa — quanto tempo o job levou, código de saída, stdout e stderr, gráficos comparativos entre execuções, e alertas em qualquer um desses mudando. Embrulhe o job no CLI do Cronitor ou faça ping da URL direto no início, fim e falha. O dashboard é voltado para times; uma casa usando metade dos recursos ainda vai ter valor só dos gráficos de runtime.
Onde fica aquém: Apenas hospedado — sem opção self-hosted. O nível gratuito é 5 monitores, que preenche rápido em um servidor ocupado.
Plataformas: Qualquer host que possa fazer HTTPS de saída. CLI wrapper para Linux, macOS, Windows.
Baixar: Cronitor download
Conclusão: A escolha certa quando você quer gráficos de runtime por job e está confortável com um serviço hospedado.
3. Dead Man’s Snitch — melhor o serviço de heartbeat original
Dead Man’s Snitch popularizou o padrão e continua sendo uma das formas mais fáceis de pegar uma falha silenciosa. Crie um snitch, obtenha uma URL, faça o job atingir aquela URL, obtenha um email se a URL não for pinguada dentro do intervalo. Esse é o produto inteiro. Quando “há algo que precisa ser mais complicado que isso?” é a pergunta certa, Dead Man’s Snitch é a resposta honesta.
Onde fica aquém: O nível gratuito é um snitch — é suficiente para proteger um job crítico e nada mais. A profundidade de recursos fica atrás de Healthchecks e Cronitor.
Plataformas: Qualquer host que possa fazer HTTPS de saída.
Baixar: Dead Man’s Snitch signup
Conclusão: A escolha certa quando o alerta “backup não executou” é o único resultado que você precisa proteger.
4. Uptime Kuma — melhor monitor de uptime self-hosted com modo push
Uptime Kuma é o monitor de uptime self-hosted que cresceu com um modo push adequado junto com suas probes HTTP e TCP. UI point-and-click, a maioria dos canais de alerta que as pessoas se importam, páginas de status por checagem, e o mesmo modelo “checagem enviada dentro de X segundos” que Healthchecks. Se o servidor doméstico já roda Uptime Kuma para a pilha de mídia, adicionar heartbeats de jobs cron no mesmo dashboard custa alguns cliques.
Onde fica aquém: O suporte modo push é mais novo que as probes modo pull e é onde as arestas mais ásperas estão. Menos especializado no caso de uso de heartbeat cron que Healthchecks.
Plataformas: Linux (Docker), Windows, macOS.
Baixar: Uptime Kuma install
Conclusão: A escolha certa quando a casa já roda Uptime Kuma e não quer outro dashboard.
5. Prometheus Node Exporter — melhores métricas para status de systemd timer
Prometheus Node Exporter envia um coletor para status de unit e timer do systemd. Combinado com Prometheus e Alertmanager, você pode representar “quando este timer executou com sucesso pela última vez,” alertar em “sem execução bem-sucedida nos últimos N minutos,” e correlacionar com métricas do sistema amplo (CPU, disco, rede). Essa é a abordagem de resistência industrial; excesso para uma casa, exatamente a forma certa para quem já roda Prometheus.
Onde fica aquém: Requer a pilha inteira de Prometheus para ser útil — essa é infraestrutura real, não uma instalação de cinco minutos. Específica de systemd para o coletor de timer; jobs cron precisam de uma abordagem diferente.
Plataformas: Linux, Windows, macOS, FreeBSD.
Baixar: Prometheus Node Exporter releases
Conclusão: A escolha certa quando Prometheus já é o armazém de métricas no homelab.
6. systemd — melhor detecção nativa de falhas no Linux
systemd no Linux moderno tem mais tratamento de falhas embutido do que a maioria dos migrantes de cron percebe. Uma unit com OnFailure= dispara outra unit quando falha, que pode ser um script mail, um webhook, ou um script que faz ping em Healthchecks. systemctl list-timers mostra o cronograma e última execução, e systemctl status <unit> mostra o código de saída e cauda de log. Para quem já está em systemd timers, metade do monitoramento já está na caixa.
Onde fica aquém: Só te diz quando o processo falhou, não quando o resultado falhou. Um script de backup que terminou mas não fez nada útil se parece verde para systemd.
Plataformas: Linux (distribuições baseadas em systemd).
Baixar: systemd resources
Conclusão: O mínimo correto em qualquer servidor Linux rodando systemd timers.
7. Gotify — melhor servidor de notificação push self-hosted
Gotify é o pequeno servidor Go que transforma qualquer requisição HTTP em uma notificação push Android. Por si só não detecta falhas; combinado com qualquer uma das ferramentas acima, se torna a forma que alertas realmente atingem um telefone sem depender de Firebase Cloud Messaging ou um serviço de notificação de terceiros. Ideal para casas onde o canal de alerta precisa ser tão privado quanto os servidores sendo monitorados.
Onde fica aquém: Não é um monitor por si só. Requer que o app Android esteja instalado nos telefones receptores; suporte iOS depende de ntfy ou similar em vez do próprio app do Gotify.
Plataformas: Linux (Docker), Windows, macOS, FreeBSD.
Baixar: Gotify install
Conclusão: O servidor de notificação push de última milha correto para uma pilha de alerta self-hosted.
Como escolher o certo
- Se você quer um dead-man switch que funcione hoje: Healthchecks.io (self-host uma vez que cresça além de 20 checagens).
- Se você quer telemetria de runtime por job e está confortável com um serviço hospedado: Cronitor.
- Se você só precisa proteger um job crítico: Dead Man’s Snitch.
- Se o servidor doméstico já roda Uptime Kuma: Uptime Kuma.
- Se Prometheus já é o armazém de métricas: Prometheus Node Exporter.
- Se o servidor Linux roda systemd timers e você quer o monitoramento embutido: systemd.
- Se você quer que alertas atinjam os telefones da casa sem passar por um serviço push de terceiros: Gotify.
Para a maioria dos homelabs, a combinação funcionando é Healthchecks (self-hosted) como dead-man switch, ligada a Gotify para push de telefone e email como fallback. Qualquer coisa rodando como um systemd timer recebe uma unit OnFailure= que faz ping no mesmo endpoint de Healthchecks em falha para que os dois sinais se correlacionem.
FAQ
Qual é a diferença entre um heartbeat e um health check?
Um heartbeat é o job dizendo “eu executei e tive sucesso.” Um health check é um monitor pesquisando o serviço para ver se responde. Heartbeats pegam falhas silenciosas de tarefas agendadas; health checks pegam falhas de serviço em runtime. Você quer ambos.
Para onde devo enviar os alertas?
Para algum lugar fora da máquina sendo monitorada. Email é bom como fallback mas não deveria ser o único canal — se a máquina rodando email é a máquina que falhou, o alerta nunca sai. Sobreponha email mais push de telefone (ntfy, Gotify, Pushover) mais canal de chat (webhook Discord, Slack) para jobs de alta prioridade.
Como adiciono um heartbeat a um job de Windows Task Scheduler?
Embrulhe a ação em um pequeno script PowerShell que executa a tarefa real, verifica o código de saída, e chama Invoke-WebRequest contra a URL de Healthchecks ou Cronitor só quando tudo deu certo. O gancho “execute isso ao completar” do Task Scheduler não distingue sucesso e falha limpar, então faça no script.
systemd é realmente suficiente para monitoramento Linux?
Para “o processo crashou?” — sim. Para “o resultado aconteceu?” — não. Combine OnFailure= do systemd com um heartbeat que o job envia só depois que seu trabalho real termina para a imagem completa.
Ainda devo monitorar o cron em si?
Sim. Cron pode estar rodando e saudável enquanto jobs individuais silenciosamente param de disparar (sintaxe crontab ruim, mudança de permissão, usuário faltando). Uptime Kuma ou Healthchecks também podem monitorar a última hora de execução do cron em um servidor doméstico; se ficar velho, cron é o que precisa de atenção.
