Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Containers·Snapshots
TypFreigeschaltetPhaseQuick WinSchwierigkeitEinfachAufgabeAufgabe automatisierenFürDevOps & InfraFürDev TeamsServicesCronWarum HoodyHTTP-nativ
TypFreigeschaltetPhaseQuick WinSchwierigkeitEinfachAufgabeAufgabe automatisierenFürDevOps & InfraFürDev TeamsServicesCronWarum HoodyHTTP-nativ
use-cases / cron-that-expires-itself / hero
HOODY CRON / SELBSTLÖSCHENDE EINTRÄGE
Der Cron-Job, der sich selbst löscht, wenn du fertig bist
Du jagst einen flackrigen Bug? Dump den Process-Tree jede Minute, 48 Stunden lang — und dann nie wieder. POSTe einen verwalteten Cron-Eintrag mit gesetztem expires_at, und der Schedule hat eine Halbwertszeit — keine Erinnerung, kein Cleanup-PR, kein veralteter Eintrag in sechs Monaten.
cron.containers.hoody.com
https://cron.containers.hoody.com/api/v1/cron/users/me/entrieslive
idschedulecommandexpiresstatus
- a1f2*/5 * * * *curl -fsS http://prod/healthniepermanent
- c4b90 3 * * */usr/local/bin/backup.shniepermanent
- e7d3* * * * *pgrep auth | tee -a tree.log2026-05-06T11:14:00Zläuft ab
- 9b21@hourlypsql -c 'VACUUM ANALYZE'niepermanent
- f0a80 9 * * 1-5/srv/cron/digest.sh2026-05-31T09:00:00Zaktiv
Eintrag e7d3läuft ab in 02:14:37
POST/users/me/entriesRequest-Body
{ "schedule": "* * * * *", "command": "pgrep auth | tee -a tree.log", "expires_at": "2026-05-06T11:14:00Z" }
POST /users/me/entries mit expires_at — der Eintrag läuft jede Minute und entfernt sich zum Stichtag selbst
use-cases / cron-that-expires-itself / lifecycle
Ein Schedule mit Halbwertszeit
Drei Momente. Eintrag mit Stichtag erstellen. Schedule läuft von allein. Bei expires_at löscht sich der Eintrag selbst — und deine Crontab ist wieder so, wie sie vor dem Debugging war.
Lebenszyklus eines selbstlöschenden Eintragscreate → run → expire
01 / CREATE
POST mit expires_at
Schick einen verwalteten Cron-Eintrag mit Schedule, Command und einem expires_at-Timestamp 48 Stunden in der Zukunft an die API. Du bekommst eine id zurück und die Bestätigung, dass der Eintrag aktiv ist.
02 / RUN
Läuft nach Schedule
Der Eintrag wird bei jedem Tick seines Cron-Ausdrucks ausgeführt — jede Minute, jede Stunde, was immer du gesetzt hast. Identisches Verhalten wie ein permanenter Eintrag, mit einem stillen Unterschied.
03 / EXPIRE
Löscht sich zum Stichtag
Sobald die Wanduhr expires_at überschreitet, wird der Eintrag entfernt. Kein letzter Run, keine Zombie-Zeile, kein manuelles Aufräumen. GET /entries gibt die Liste zurück, die es ohne dich gegeben hätte.
Kein Cleanup-Skript. Keine Kalender-Erinnerung. Kein teamweiter "Wem gehört das?"-Thread in sechs Monaten. Der Eintrag wusste, wann er sterben sollte, und hat es getan.
use-cases / cron-that-expires-itself / mechanism
Zwei Curls und eine Uhr
Eintrag mit POST anlegen. 49 Stunden später per GET prüfen, dass er weg ist. Der ganze Mechanismus sind zwei HTTP-Calls und ein Timestamp — kein Cron-Daemon, in den du dich per SSH einwählen müsstest, keine /etc/crontab, die du editieren musst.
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.
Das expires_at-Feld ist der Vertrag. Du musst dich nicht ans Aufräumen erinnern, weil Erinnern nicht Teil des Protokolls ist — der Stichtag ist es.
use-cases / cron-that-expires-itself / powers
Was die Halbwertszeit freischaltet
Sobald der Schedule ein Verfallsdatum hat, sind drei Dinge nicht mehr dein Problem: Drift, Aufsicht und Audit-Müdigkeit. Die Crontab bleibt von Haus aus sauber.
KEIN DRIFT
Crontab kann nicht zuwuchern
Jeder "ich mach das nur kurz…"-Eintrag hat einen Stichtag eingebaut. Die Crontab beschneidet sich selbst — kein Quartals-Aufräumen, keine veralteten Zeilen, die niemand löschen will, weil niemand weiß, was sie taten.
KEINE AUFSICHT
Vergessen ist okay
Du musst dich nicht erinnern, den Eintrag zu entfernen. Du musst keine Kalender-Erinnerung setzen. Du musst keinen Cleanup-PR einreichen. Der Stichtag ist die Erinnerung — und er feuert immer.
AUDITIERBAR
Logs überleben den Eintrag
Der Eintrag ist weg, aber die Runs nicht. Jede Ausführung hat noch ihre Log-Zeile, ihren Exit-Code und Timestamp — die Spur "das lief 48 Stunden und stoppte dann" ist nachträglich vollständig rekonstruierbar.
use-cases / cron-that-expires-itself / capacity
Günstig, schnell, beliebig viele
Selbstlöschende Einträge kosten dasselbe wie permanente. Stack so viele, wie du brauchst — die API wurde für den Fall gebaut, dass jeder Debugger im Team drei oder vier temporäre Jobs gleichzeitig laufen hat.
- MIN. AUFLÖSUNG1 min
Standard-Cron-Ausdrücke, bis runter zu einer Minute. Das expires_at-Feld akzeptiert jeden RFC-3339-Timestamp.
- PRO ACCOUNT100s
Reichlich Platz für ein Team von Debuggern, die jeweils eine Handvoll temporärer Probes neben den permanenten Jobs laufen lassen.
- MANUELLE SCHRITTE0 cleanup
Kein DELETE-Call, an den man sich erinnern müsste. Kein "alte Crons aufräumen"-Ticket auf dem Backlog. Der Eintrag erledigt sein eigenes Lebensende.
Limits skalieren mit der Cron-Service-Stufe deines Accounts. Logs werden nach dem standardmäßigen Hoody-Cron-Retention-Fenster aufbewahrt, auch nachdem der Eintrag selbst abgelaufen ist.
use-cases / cron-that-expires-itself / punchline
Temporäre Arbeit sollte keine permanenten Crontab-Einträge hinterlassen.
der alte Wegder Halbwertszeit-Weg
OHNE expires_atecho '* * * * * pgrep auth …' >> /etc/crontabund eine Kalender-Erinnerung, die du ignorieren wirst
MIT expires_atPOST /entries [ expires_at: "+48h" ]der Schedule löscht sich zum Stichtag selbst
use-cases / cron-that-expires-itself / replaces
Was das ersetzt
Die Muster, zu denen Entwickler greifen, wenn sie eine einmalige Cron-Zeile brauchen. Jedes hinterlässt eine Spur. expires_at fegt sie weg.
- Manuelles Crontab-AufräumenWöchentliches Grep nach "DELETE_AFTER"-Kommentaren
- "TODO: entfernen"-NotizenKlebt am Monitor. Verblasst nach einem Sprint.
- Terraform-Cron-LifecycleZwei PRs, um eine einmalige Aufgabe zu schedulen
- Custom Janitor-JobsEin zweiter Cron, dessen einziger Zweck es ist, den ersten zu killen
- Slack-Erinnerungs-ThreadsEin zukünftiger Mensch als dein Garbage Collector
- GitHub-Issue + Cron-SelbstauditEin wöchentliches Meeting, um über Cron-Zeilen zu reden
use-cases / cron-that-expires-itself / cta
Temporäre Arbeit sollte keine permanenten Crontab-Einträge hinterlassen.
use-cases / cron-that-expires-itself / related
Lies die anderen
