
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.
Das meiste Monitoring beobachtet, was passiert ist. Du brauchtest etwas, das beobachtet, was nicht passiert ist. Zwei Cron-Einträge — einer schlägt, einer hört auf das Ausbleiben des Schlags — und die Page, die dich am Strand erreicht.
zwei Cron-Einträge · null neue Services · der Alarm findet dich, wenn nichts passiert
Der Job, den du schon hattest, macht weiter seine Arbeit. Wenn er fertig ist, fügt er ein curl hinzu: eine Heartbeat-Zeile an einen Notifications-Endpoint. Ein zweiter Cron-Eintrag läuft in seiner eigenen Kadenz und prüft auf Stille — wenn kein frischer Beat da ist, alarmiert er dein Handy. Der Erfolg des Jobs ist still. Sein Ausbleiben ist laut.
Zwei POSTs an /users/root/entries mit Fünf-Feld-Expressions. Der erste läuft nach jedem geplanten Job und postet seinen Heartbeat. Der zweite läuft in eigener Kadenz, fragt den Notifications-Endpoint, ob der letzte Beat frisch genug ist, und löst die Page aus, wenn nicht. Keine Queue, kein Agent, kein Daemon — nur zwei Crontab-Zeilen, die ohnehin existieren mussten.
Die meisten Monitoring-Tools beobachten den Erfolgspfad: sie alarmieren, wenn etwas passiert. Diese Form alarmiert, wenn nichts passiert — und das ist der Fall, den die stillen Jobs immer verlieren.
Wenn der Worker-Prozess nie startet — die Box hat rebootet, das Skript wurde gelöscht, ein Quota lief ab — gibt es nichts zu loggen und nichts, worauf alarmiert werden könnte. Der Watcher-Cron läuft trotzdem und merkt, dass die Heartbeat-Zeile abgestanden ist. Das, was den stillen Crash fängt, ist genau das, was nicht von der stillen Sache abhängt.
Der Monitor ist eine zusätzliche Crontab-Zeile, kein Healthchecks.io-Account und kein CloudWatch-Alarm. Er ist an denselben Container wie die Arbeit gebunden, läuft mit `expires_at` ab, wenn du das willst, und liest aus derselben Notifications-API, die der Rest deines Stacks ohnehin nutzt.
Der Notifications-Endpoint fan-outet die Page über Push, SMS und Email — die Kanäle, denen du ohnehin vertraust. Du beobachtest das Dashboard nicht. Das Dashboard beobachtet sich selbst und findet dich nur am Strand auf Bali, wenn die Stille zu lange angedauert hat.
Der Mechanismus ist schlichtes Hoody Cron und Hoody Notifications. Die Zahlen kommen aus der dokumentierten API-Surface, nicht aus einer Demo-Runtime.
Standard 5-Feld-Expressions plus Macros — `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. Watcher und Worker können komplett unterschiedliche Kadenzen haben.
Managed Entries unterstützen `expires_at`, sodass ein temporärer Heartbeat (z.B. ein einwöchiges Migrationsfenster) sich selbst aufräumt. Der Watcher verschwindet mit der Arbeit.
Jeder Container bekommt seine eigene Crontab. Der Heartbeat eines Tenants kann den Watcher eines anderen nicht stummschalten, und einen Job zu deaktivieren ist ein einzelnes PATCH `enabled: false`.
Limits gemäß Hoody Cron API: 5-Feld-Expressions plus die Macros `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly`, optionales `expires_at` auf Managed Entries, Per-User-Crontab-Isolation, Aktivieren/Deaktivieren via PATCH.
Stille ist jetzt ein Alarm.
Die Standard-Greift-Tools, wenn du einen Cron-Monitor mit Paging willst. Jedes davon ist ein eigener Account, eine eigene Rechnung, eine eigene API. Zwei Crontab-Zeilen und der Notifications-Endpoint machen denselben Job.
Hör auf, den Erfolgspfad zu beobachten. Beobachte die Abwesenheit von Erfolg — das ist der einzige Ort, an dem die stillen Failures leben.