Sesenta contenedores en un servidor
Un servidor bare-metal ejecuta decenas a cientos de contenedores Hoody. KSM y dedup BTRFS hacen que el costo marginal sea casi cero.
Containers·Snapshots
TipoDesbloqueadoEtapaVictoria rápidaDificultadSimpleTrabajoAutomatizar tareaParaDevOps e infraParaEquipos de desarrolloServiciosCronPor qué HoodyHTTP nativo
TipoDesbloqueadoEtapaVictoria rápidaDificultadSimpleTrabajoAutomatizar tareaParaDevOps e infraParaEquipos de desarrolloServiciosCronPor qué HoodyHTTP nativo
use-cases / cron-that-expires-itself / hero
HOODY CRON / ENTRADAS QUE EXPIRAN SOLAS
El cron que se borra solo cuando terminas
¿Persiguiendo un bug intermitente? Vuelca el árbol de procesos cada minuto durante 48 horas, y luego nunca más. Haz POST a una entrada de cron gestionada con expires_at fijado, y el horario tendrá vida media — sin recordatorio, sin PR de limpieza, sin entrada huérfana seis meses después.
cron.containers.hoody.com
https://cron.containers.hoody.com/api/v1/cron/users/me/entriesen vivo
idhorariocomandoexpiraestado
- a1f2*/5 * * * *curl -fsS http://prod/healthnuncapermanente
- c4b90 3 * * */usr/local/bin/backup.shnuncapermanente
- e7d3* * * * *pgrep auth | tee -a tree.log2026-05-06T11:14:00Zexpirando
- 9b21@hourlypsql -c 'VACUUM ANALYZE'nuncapermanente
- f0a80 9 * * 1-5/srv/cron/digest.sh2026-05-31T09:00:00Zactiva
entrada e7d3expira en 02:14:37
POST/users/me/entriescuerpo de la solicitud
{ "schedule": "* * * * *", "command": "pgrep auth | tee -a tree.log", "expires_at": "2026-05-06T11:14:00Z" }
POST /users/me/entries con expires_at — la entrada se ejecuta cada minuto y luego se elimina sola al llegar la fecha límite
use-cases / cron-that-expires-itself / lifecycle
Un horario con vida media
Tres momentos. Crea la entrada con una fecha límite. El horario se ejecuta solo. Al llegar expires_at, la entrada se borra a sí misma — y tu crontab vuelve a estar como antes de empezar a depurar.
Ciclo de vida de una entrada que expira solacrear → ejecutar → expirar
01 / CREAR
POST con expires_at
Envía una entrada de cron gestionada a la API con horario, comando y un timestamp expires_at a 48 horas vista. Recibes un id y la confirmación de que la entrada está activa.
02 / EJECUTAR
Se ejecuta según el horario
La entrada se ejecuta en cada tick de su expresión cron — cada minuto, cada hora, lo que hayas configurado. Comportamiento idéntico al de una entrada permanente, con una diferencia silenciosa.
03 / EXPIRAR
Se borra sola al llegar la fecha límite
Cuando el reloj de pared cruza expires_at, la entrada se elimina. Sin ejecución final, sin fila zombi, sin limpieza manual. GET /entries devuelve la lista que habrías tenido sin ti.
Sin script de limpieza. Sin recordatorio en el calendario. Sin un hilo de equipo "¿quién es dueño de esto?" dentro de seis meses. La entrada sabía cuándo le tocaba morir y lo hizo.
use-cases / cron-that-expires-itself / mechanism
Dos curls y un reloj
Crea la entrada con un POST. Verifica que ya no está con un GET 49 horas después. Todo el mecanismo son dos llamadas HTTP y un timestamp — sin demonio cron al que entrar por SSH, sin /etc/crontab que editar.
create.sh
POST# 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 }
verify.sh
GET# 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.
El campo expires_at es el contrato. No tienes que acordarte de limpiar porque acordarse no forma parte del protocolo — la fecha límite sí.
use-cases / cron-that-expires-itself / powers
Lo que desbloquea la vida media
En cuanto el horario tiene fecha de caducidad, tres cosas dejan de ser problema tuyo: deriva, supervisión y fatiga de auditoría. El crontab se mantiene limpio por defecto.
SIN DERIVA
El crontab no se acumula
Cada entrada "solo voy a poner esto temporalmente…" lleva fecha límite incorporada. El crontab se autopoda — sin barridos trimestrales de limpieza, sin filas obsoletas que nadie quiere borrar porque nadie sabe qué hacían.
SIN SUPERVISIÓN
Olvidarse está bien
No tienes que acordarte de quitar la entrada. No tienes que poner un recordatorio en el calendario. No tienes que abrir un PR de limpieza. La fecha límite es el recordatorio — y siempre dispara.
AUDITABLE
Los logs sobreviven a la entrada
La entrada se fue, pero las ejecuciones no. Cada ejecución sigue teniendo su línea de log, su exit code y su timestamp — así que el rastro de "esto corrió 48 horas y luego paró" se puede reconstruir entero después.
use-cases / cron-that-expires-itself / capacity
Baratas, rápidas, plurales
Las entradas que expiran solas cuestan lo mismo que las permanentes. Apila tantas como necesites — la API se diseñó para el caso en que cada quien del equipo depurando tiene tres o cuatro jobs temporales corriendo a la vez.
- GRANULARIDAD MÍN.1 min
Expresiones cron estándar, hasta resolución de un minuto. El campo expires_at acepta cualquier timestamp RFC 3339.
- POR CUENTA100s
Espacio de sobra para un equipo de depuradores ejecutando un puñado de sondas temporales junto a los jobs permanentes.
- PASOS MANUALES0 limpieza
Sin llamada DELETE que recordar. Sin ticket de "limpiar crons viejos" en el backlog. La entrada se ocupa de su propio fin de vida.
Los límites escalan con el tier del servicio cron de tu cuenta. Los logs se conservan según la ventana estándar de retención de Hoody Cron una vez que la entrada en sí ha expirado.
use-cases / cron-that-expires-itself / punchline
El trabajo temporal no debería dejar entradas permanentes en el crontab.
el modo viejoel modo de vida media
SIN expires_atecho '* * * * * pgrep auth …' >> /etc/crontaby un recordatorio en el calendario que vas a ignorar
CON expires_atPOST /entries [ expires_at: "+48h" ]el horario se borra solo al llegar la fecha límite
use-cases / cron-that-expires-itself / replaces
Lo que esto reemplaza
Los patrones a los que se recurre cuando hace falta una línea de cron de un solo uso. Cada uno deja rastro. expires_at lo barre.
- Poda manual del crontabUn grep semanal por comentarios "DELETE_AFTER"
- Notas "TODO: quitar esto"Pegada al monitor. Se desvanece tras un sprint.
- Lifecycle de cron en TerraformDos PRs para programar trabajo de un solo uso
- Jobs janitor a medidaUn segundo cron cuyo único trabajo es matar al primero
- Hilos de recordatorio en SlackUn humano del futuro como tu garbage collector
- Issue de GitHub + autoauditoría de cronUna reunión semanal para hablar de líneas de cron
use-cases / cron-that-expires-itself / cta
El trabajo temporal no debería dejar entradas permanentes en el crontab.
use-cases / cron-that-expires-itself / related
Lee los otros
