Wie du zeitgesteuerte KI-Aufgaben in HYPDB.ONE anlegst — mit dem Format, das die laufenden Jobs tatsaechlich benutzen. Alle Beispiel-Config und alle Zahlen auf dieser Seite sind am System gemessen, nicht erfunden.
Jedes Hermes-Profil hat sein eigenes Verzeichnis. Die Jobs stehen in JSON, nicht in YAML. Eine Datei pro Profil:
| Profil | Datei | Jobs (gemessen) |
|---|---|---|
| default | ~/.hermes/cron/jobs.json | — |
| hermes-system-linux | ~/.hermes/profiles/hermes-system-linux/cron/jobs.json | — |
| hypdb-creator | ~/.hermes/profiles/hypdb-creator/cron/jobs.json | — |
| jarvis | ~/.hermes/profiles/jarvis/cron/jobs.json | — |
| Gesamt | 4 Dateien | — |
Innerhalb einer Datei ist es ein Objekt mit jobs (Array) und updated_at:
Es gibt kein YAML-Format. Die Schluessel goal, context, steps, deliver_to, profile und timeout existieren im echten jobs.json nicht. Eine Anleitung, die sie zeigt, beschreibt eine Datei, die der Scheduler nicht liest — der Job startet nie und der Fehler bleibt still.
Die Aufgabe steckt im Feld prompt. Das Ziel im Feld deliver. Das Zeitlimit in timeout_seconds.
schedule ist ein Objekt mit kind. Genau drei Arten kommen im laufenden System vor:
| kind | Zusatzfeld | Bedeutung | Anzahl (gemessen) |
|---|---|---|---|
| cron | expr | Standard-Cron-Ausdruck (Min St Tag Mon Woch) | — |
| interval | minutes | alle n Minuten, unabhaengig von der Uhrzeit | — |
| once | run_at | einmalig zu einem Zeitpunkt, danach inaktiv | — |
Die im System tatsaechlich verwendeten Cron-Ausdruecke, ohne Duplikate:
interval richtet sich nicht nach der Uhrzeit. Ein Job mit minutes: 5 laeuft alle 5 Minuten — auch um 03:12 nachts. Fuer eine spaetere Umstellung des Systems (Neustart um 04:00) zaehlt das genaue Intervall. cron ist fuer feste Uhrzeiten.
Ein vollstaendiger Job hat rund 35 Felder. Die, die man wirklich setzt, sind diese:
Zwei Betriebsarten, und das ist der wichtigste Unterschied:
no_agent: false): Das prompt geht an ein Sprachmodell, das die Aufgabe selbst plant. Braucht model + provider.no_agent: true plus script): Nur das Skript laeuft, es wird kein Modell belastet. Kostet nichts und ist fuer Statusabfragen die richtige Wahl.Ein reiner Statuscheck braucht kein Modell. no_agent: true + script ist schneller, kostenlos und laeuft auch dann, wenn der Modellanbieter nicht erreichbar ist.
Zustellziele (deliver). Nur diese drei Formen kommen vor:
| Wert | Bedeutung | Anzahl (gemessen) |
|---|---|---|
| local | Nur in der lokalen Ablage — das Ergebnis erscheint im Chat-Verlauf, es wird nichts versendet. | 38 |
| local,telegram:<chat-id> | Lokal und als Telegram-Nachricht an die konkrete Chat-ID. | 5 |
| local,bot-chat:default | Lokal und im Bot-Chat des Standardprofils. | 4 |
| (kein Feld) | Ein Job ohne deliver-Feld — er steht auf state: "geplant". | 1 |
Die Kanaele sind Kommalisten: local steht in allen drei Varianten, die Zustellung ist also additiv.
Es gibt in diesem System keinen E-Mail-Zustellweg fuer Cron-Ergebnisse. deliver kennt genau die drei Formen oben. Eine Anleitung, die „Versand als formatiertes E-Mail-Bericht" anbietet, beschreibt eine Faehigkeit, die nicht existiert.
Ein Job kann enabled: true haben und trotzdem jeden Lauf vermasseln. Die Zustandsfelder trennen das:
| Feld | Bedeutung |
|---|---|
| enabled | Ist der Job ueberhaupt eingeplant? false = nie laeuft. |
| last_status | Ergebnis des letzten Laufs: ok oder error. |
| last_error | Die Fehlermeldung des letzten Fehlschlags im Klartext. |
| failure_streak | Anzahl aufeinanderfolgender Fehlschlaege. Der wichtigste Wert. |
| last_run_at / next_run_at | Wann er zuletzt lief, wann er als naechstes laeuft. |
| paused_at / paused_reason | Wurde er von Hand angehalten — und warum. |
| last_dispatch | Verspaetung in Sekunden und kind (on_time / late). |
Stand des laufenden Systems, bei jedem Seitenaufruf aus /api/automation gezaehlt:
| Kennzahl | Wert | Quelle |
|---|---|---|
| Jobs gesamt | — | aufgaben.length |
| davon enabled | — | aufgaben[].enabled |
| state = aktiv | — | aufgaben[].state |
| state = Fehler | — | aufgaben[].state |
| state = pausiert | — | aufgaben[].state |
| state = geplant | — | aufgaben[].state |
| Erfolgsquote (Serverangabe) | — | leistung.erfolgsquote_pct |
Die Antwort enthaelt leistung.aktiv — und leistung.fehler —. Die Liste aufgaben[] zaehlt dagegen — aktive und — fehlerhafte Jobs. enabled: true ist etwas anderes als state: "aktiv": ein Job kann eingeplant sein und trotzdem im Fehlerzustand stehen. Beide Zahlen sind dieselbe Quelle — die Aggregate zaehlen die eingeschalteten Jobs, die Liste zaehlt den aktuellen Zustand.
Im Profil default steht der Job hypdb-backup-restore auf enabled: false und last_status: error mit failure_streak: 607. Er ist also seit 607 Versuchen fehlgeschlagen — und haette trotzdem weitergelaufen, wenn er aktiviert gewesen waere. Ein deaktivierter Job mit hohem Streak ist kein gesunder Job, sondern ein Totalausfall, der nichts mehr kostet.
Umgekehrt: pdf zeigt failure_streak: 196 (nachgemessen 05.10.2026) bei enabled: false und last_status: ok. Ein alter Streak bleibt stehen, nachdem der Job abgeschaltet wurde — last_status ist die juengere und verlaesslichere Angabe.
Reihenfolge, die sich bewahrt hat:
jobs.json unter dem Profil? Eine kaputte Datei wird still ignoriert.kind und das passende Zusatzfeld. kind: cron ohne expr ist ungueltig.model und provider zusammenpassen — ein unbekannter Slug endet mit 404 model not found bei jedem Lauf.last_status, last_error und failure_streak lesen.Ein Job mit falschem Zeitplan oder fehlendem Modell meldet sich nicht. Er steht einfach auf enabled: true, macht alle 30 Minuten nichts und liefert dieselbe Fehlermeldung. Deshalb gehoert failure_streak in jede Ueberwachung — nicht nur enabled.
Ein Job kann mehrere Schritte enthalten — aber nicht ueber ein steps-Feld, denn das gibt es nicht. Es gibt zwei Wege:
Weg 1 — Skript (no_agent: true): Die Logik liegt in script. Das Skript kann beliebig viele Schritte machen, speichern und zusammenfassen. Der Job liefert nur das Ergebnis von local.
Weg 2 — Prompt (no_agent: false): Der Auftrag steht als Text im prompt. Auch mehrstufig, aber als Anweisung an das Modell, nicht als Liste von Schritten im Format.
Ein Skript-Job muss im Skript-Verzeichnis des Profils liegen. Ein script-Wert, dessen Datei fehlt, laeuft still ins Leere — im System gibt es einen eingebauten Watchdog genau fuer diesen Fall.