Cron-Automation
▸ Was diese Seite ist — und was die frühere Fassung behauptete
Cron-Automation ist ein planbarer Ablauf: Aufträge laufen zu festen Zeiten oder im festen Takt, jeder mit eigenem Status und Protokoll. Diese Seite fragt beim Laden die Automations-API ab und zeigt die tatsächlich geplanten Aufträge dieses Systems — Namen, Zeitpläne, letzter Lauf, Zustand.
Die frühere Fassung hatte keinen einzigen Anschluss an ein Backend. Sie zeigte einen erfundenen Ablauf mit Kategorie = tick % 8 und einem Beispielskript, dessen Schritt 3 „HTML generieren + deployen" hieß — es gibt keinen Deploy-Schritt und kein Deploy-Skript im Webroot (TICK357). Der Ablauf war beschrieben, nicht belegt.
Auch das Skript am Ende dieser Seite war tot: Es griff auf navToggle und navLinks zu — keine der beiden IDs existiert im Dokument. Es lief ohne Fehlermeldung ins Leere. Diese Fassung entfernt es.
Was es kann
Mit Cron-Automation laufen wiederkehrende Aufgaben getaktet statt ad hoc, mit sichtbarem Zustand je Auftrag:
- Geplante Initiierung von Agenten-Aufgaben — Research-Zyklen, Status-Abfragen, Wartungsläufe
- Ergebnis-Generierung in festen Ausgabeformaten (Seiten, Reports, Status-Dateien)
- Verifikation nach Ausführung — die Tabelle unten zeigt je Auftrag den letzten Lauf
- Fehlerbehandlung mit sichtbarem Status — Fehler sind hier als eigener Zustand ausgewiesen, nicht versteckt
Die tatsächlich geplanten Aufträge — live geprüft
Der Text oben nennt Fähigkeiten. Diese Seite fragt den Server, was er tatsächlich geplant hat. Angezeigt wird der Status dieses Aufrufs, nicht ein fester Stand.
Aufträge werden geladen …
| # | Auftrag | Zeitplan | Profil | Letzter Lauf | Zustand |
|---|
Wird geladen …
Zeitplan-Arten, die der Server tatsächlich kennt
Der Plan ist bei jedem Auftrag ein String — kein Objekt, kein Intervall-Feld. Welche der beiden Schreibweisen wie oft vorkommt, sagt die Zählung unten; sie wird beim Laden gemessen, nicht eingetragen:
Die im System wirklich vorkommenden Intervall-Takte (Häufigkeit aus derselben Antwort):
wird gemessen …
Die vorkommenden Cron-Ausdrücke — Uhrzeiten im 24-h-Format, keine Namen für Wochentag oder Monat:
wird gemessen …
Wer einen Auftrag von Hand anlegt, muss also wissen, welche der beiden Schreibweisen das System erwartet. Beide sind live belegt; welche davon der Scheduler tatsächlich auswertet, ist aus der API-Antwort allein nicht ablesbar — die Seite behauptet es deshalb nicht.
- Cron-Ausdruck, z. B.
0 */3 * * *(alle 3 Stunden),*/15 * * * *(alle 15 Minuten),30 8 * * 1-5(werktags 8:30). Erweiterungen wieMON/JANoder Schritte wie*/3in der Minute kommen in dieser Liste nicht vor. - Intervall-Schreibweise, z. B.
every 5m,every 60m,every 360m. Das ist eine eigene Schreibweise des Servers, kein Cron-Ausdruck — in einer crontab wäre sie ungültig.
Wer einen Auftrag von Hand anlegt, muss also wissen, welche der beiden Schreibweisen das System erwartet. Beide sind live belegt; welche davon der Scheduler tatsächlich auswertet, ist aus der API-Antwort allein nicht ablesbar.
Die Dienste, die einen Lauf möglich machen
Cron-Automation ist kein Einzelprogramm: die Automations-API meldet mit derselben Antwort, welche Dienste des Stacks bei diesem Aufruf erreichbar waren. Auch diese Zeilen werden beim Laden gemessen:
Dienste werden gemessen …
| Dienst | Port | Zustand |
|---|---|---|
| Messung läuft … | ||
Wird gemessen …
Wie ein Lauf abläuft
Der Ablauf ist derselbe wie auf dieser Seite vor der Korrektur beschrieben — diesmal aber mit den Feldern, die die API wirklich liefert:
name Auftragsname, frei wählbar z. B. "agenten-status-frisch"
schedule Zeitplan als STRING z. B. "every 5m" oder "*/15 * * * *"
state Serverzustand "aktiv" | "pausiert" | "Fehler"
enabled Schalter true | false
last letzter Lauf, ISO-Zeitstempel "2026-10-05T00:24:32"
profile ausführendes Profil hermes-system-linux | jarvis | ...
script Skript, nur bei 27 von 47 belegt "" bei 20 Aufträufen
▸ Zwei Auffälligkeiten, die man kennen sollte
Das Feld script ist nur bei 27 von 47 Aufträgen belegt. Bei 20 Aufträgen steht ein leerer String dort. Die Seite behauptet nicht, dass diese 20 ohne Skript auskommen — das Feld sagt nur, dass dort kein Pfad hinterlegt ist.
Der Zähler aktiv der API stimmt nicht mit der Liste überein. leistung.aktiv meldet einen Wert, der der Zahl der eingeschalteten Aufträge entspricht, während die Zustandsliste aktiv einen kleineren Wert zählt. Die Tabelle unten zeigt die gezählten Zustände, nicht den Summenwert der API — sonst widerspräche sich die Seite in zwei Spalten.
Was Cron-Automation nicht ist
| Annahme | Befund | Geprüft über |
|---|---|---|
| „Schritt 3: HTML generieren + deployen" | existiert nicht — kein Deploy-Skript, kein Deploy-Befehl | find . -iname "*deploy*" -maxdepth 2 ohne Treffer außer der Seite |
| „Kategorie = tick % 8" | erfunden — 8 Kategorien gibt es im Auftragsfeld nicht | 47 Aufträge, Feld typ ist überall Cron |
| Ein Workflow-Queue oder Review-Gate | existiert nicht | /api/automation führt aufgaben, protokolle, dienste, endpunkte — keine Queue |
| Jeder Auftrag läuft zuverlässig | teilweise — Fehlerzustände sind vorhanden und unten einzeln genannt | Zustand je Auftrag aus der API |
Für wen es gedacht ist
Cron-Automation ist für Teams und Selbstständige sinnvoll, die ein KI-System produktiv betreiben wollen — also mit regelmäßigen, messbaren Ergebnissen statt ad-hoc Bedienung. Typische Anwendungsfälle:
- Content- und Knowledge-Updates (regelmäßige Blog-/Guide-Erweiterungen)
- Operative Monitoring-Workflows (Status-Abfragen + Reporting)
- Wiederkehrende Wartung (Datensicherung, Platzwaechter, Zustandsprüfungen)
Diese Liste nennt keine Erfolgszahlen, weil es keine belegten gibt: Die Aufträge oben laufen auf dem Server dieses Anbieters, nicht beim Kunden. Ein Kundenlauf mit Vorher-/Nachher-Messung ist nicht dokumentiert.