
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
A maioria dos monitoramentos olha o que aconteceu. Você precisava de algo que olhasse o que não aconteceu. Duas entradas de cron — uma bate, a outra escuta a ausência da batida — e o alerta que te encontra na praia.
duas entradas de cron · zero serviços novos · o alerta te encontra quando nada acontece
O job que você já tinha continua fazendo seu trabalho. Quando termina, ele acrescenta um curl: uma linha de heartbeat para um endpoint de notificações. Uma segunda entrada de cron roda na própria cadência e checa por silêncio — se não há batida fresca, ela alerta seu celular. O sucesso do job é silencioso. A ausência dele é barulhenta.
Dois POSTs em /users/root/entries com expressões de cinco campos. O primeiro roda depois de cada job agendado e posta seu heartbeat. O segundo roda na própria cadência, pergunta ao endpoint de notificações se a última batida está fresca, e dispara o alerta se não estiver. Sem fila, sem agente, sem daemon — só duas linhas de crontab que já tinham que existir.
A maioria das ferramentas de monitoramento vigia o caminho do sucesso: alertam quando algo acontece. Esse formato alerta quando nada acontece — e esse é o caso que os jobs silenciosos sempre perdem.
Se o processo worker nunca inicia — a caixa reiniciou, o script foi deletado, uma cota expirou — não há nada para logar e nada para alertar. O cron do watcher roda mesmo assim e percebe que a linha do heartbeat está velha. O que pega a queda silenciosa é exatamente o que não depende do que está silente.
O monitor é uma linha de crontab a mais, não uma conta no Healthchecks.io ou um alarme do CloudWatch. Está atrelado ao mesmo contêiner do trabalho, expira com `expires_at` se você quiser, e lê da mesma API de notificações que o resto da sua stack já usa.
O endpoint de notificações distribui o alerta por push, SMS e email — os canais em que você já confia. Você não fica olhando o dashboard. O dashboard se vigia, e te encontra na praia em Bali só quando o silêncio já se estendeu demais.
O mecanismo é Hoody Cron e Hoody Notifications puros. Os números vêm da superfície de API documentada, não de um runtime de demo.
Expressões padrão de 5 campos mais macros — `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. O watcher e o worker podem ter cadências completamente diferentes.
Entradas gerenciadas suportam `expires_at`, então um heartbeat temporário (uma janela de migração de uma semana, digamos) se limpa sozinho. O watcher some junto com o trabalho.
Cada contêiner tem seu próprio crontab. O heartbeat de um tenant não pode silenciar o watcher de outro, e desativar um job é um único PATCH `enabled: false`.
Limites pela Hoody Cron API: expressões de 5 campos mais as macros `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly`, `expires_at` opcional em entradas gerenciadas, isolamento de crontab por usuário, ativar/desativar via PATCH.
Agora o silêncio é um alerta.
As ferramentas padrão para quando você quer um monitor de cron com paging. Cada uma é uma conta separada, uma fatura separada, uma API separada. Duas linhas de crontab e o endpoint de notificações fazem o mesmo trabalho.
Pare de observar o caminho do sucesso. Observe a ausência do sucesso — é o único lugar onde as falhas silenciosas vivem.