
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.
Caçando um bug intermitente? Faça um dump da árvore de processos a cada minuto durante 48 horas, e nunca mais. Faça POST em uma entrada gerenciada de cron com expires_at definido, e o agendamento ganha meia-vida — sem lembrete, sem PR de limpeza, sem entrada órfã seis meses depois.
{ "schedule": "* * * * *", "command": "pgrep auth | tee -a tree.log", "expires_at": "2026-05-06T11:14:00Z" }
POST /users/me/entries com expires_at — a entrada roda a cada minuto e depois se remove no prazo
Três momentos. Crie a entrada com um prazo. O agendamento roda por conta própria. Em expires_at, a entrada se apaga sozinha — e seu crontab volta ao que era antes de você começar a depurar.
Envie uma entrada gerenciada de cron para a API com schedule, command e um timestamp expires_at 48 horas adiante. Você recebe de volta um id e a confirmação de que a entrada está habilitada.
A entrada executa a cada tique da expressão cron — a cada minuto, a cada hora, o que você definir. Comportamento idêntico ao de uma entrada permanente, com uma diferença silenciosa.
Quando o relógio cruza expires_at, a entrada é removida. Sem execução final, sem linha zumbi, sem limpeza manual. GET /entries devolve a lista que devolveria sem você.
Sem script de limpeza. Sem lembrete no calendário. Sem aquela thread coletiva de "quem é o dono disso?" daqui a seis meses. A entrada sabia quando deveria morrer e morreu.
Crie a entrada com um POST. Verifique que ela sumiu com um GET 49 horas depois. O mecanismo todo são duas chamadas HTTP e um timestamp — sem daemon de cron pra entrar via SSH, sem /etc/crontab pra editar.
# create a self-deleting cron entry curl -X POST \ https://cron.containers.hoody.com/api/v1/cron/users/me/entries \ -H "Content-Type: application/json" \ -d '["schedule":"* * * * *","command":"pgrep auth | tee -a tree.log","expires_at":"2026-05-06T11:14:00Z"]' # response HTTP/1.1 201 Created { "id":"e7d3", "expires_at":"2026-05-06T11:14:00Z", "enabled":true }
# 49 hours later — list is back to normal curl GET https://cron.containers.hoody.com/api/v1/cron/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "expires_at":null, ... }, { "id":"c4b9", "expires_at":null, ... }, { "id":"9b21", "expires_at":null, ... } ] # e7d3 was here. e7d3 deleted itself.
O campo expires_at é o contrato. Você não precisa lembrar de limpar porque lembrar não faz parte do protocolo — o prazo faz.
Quando o agendamento tem data de expiração, três coisas deixam de ser seu problema: deriva, supervisão e fadiga de auditoria. O crontab fica limpo por padrão.
Toda entrada "vou colocar só temporariamente…" já vem com prazo embutido. O crontab se autopoda — sem varredura trimestral de limpeza, sem linhas órfãs que ninguém quer apagar porque ninguém sabe o que faziam.
Você não precisa lembrar de remover a entrada. Não precisa marcar lembrete no calendário. Não precisa abrir um PR de limpeza. O prazo é o lembrete — e ele sempre dispara.
A entrada se foi, mas as execuções não. Toda execução ainda tem sua linha de log, código de saída e timestamp — então o rastro de "isso rodou por 48 horas e depois parou" é totalmente reconstruível depois do fato.
Entradas auto-expiráveis custam o mesmo que as permanentes. Empilhe quantas precisar — a API foi feita para o caso em que cada pessoa do time depurando tem três ou quatro jobs temporários rodando ao mesmo tempo.
Expressões cron padrão, até a resolução de um minuto. O campo expires_at aceita qualquer timestamp RFC 3339.
Espaço de sobra para um time de pessoas depurando, cada uma rodando um punhado de sondas temporárias junto dos jobs permanentes.
Nenhuma chamada DELETE pra lembrar. Nenhum ticket de "limpar crons antigos" no backlog. A entrada cuida do próprio fim de vida.
Os limites escalam com o tier do serviço de cron na sua conta. Os logs são retidos pela janela padrão de retenção do Hoody Cron depois que a própria entrada expirou.
Trabalho temporário não deveria deixar entradas permanentes no crontab.
Os padrões para os quais as pessoas desenvolvedoras correm quando precisam de uma linha de cron one-shot. Cada um deixa rastro. expires_at varre tudo.
Trabalho temporário não deveria deixar entradas permanentes no crontab.