Totmannschalter für KI-Agenten: Erkennen, wenn ein geplanter Lauf still scheitert

Ein Totmannschalter ist ein Monitor, der planmäßig von etwas hören erwartet und alarmiert, sobald das ausbleibt. Züge haben das seit über hundert Jahren: Lässt der Fahrer den Hebel los, bremst der Zug. Auf Software übertragen ist die Idee dieselbe — ein geplanter Job soll sich melden, und Stille zählt als Fehler, nicht als Nicht-Ereignis.

Cronjobs brauchen das schon seit Jahrzehnten. Geplante KI-Agenten brauchen es noch dringender, weil sie auf eine Art scheitern, die reines Cron kaum kennt: Sie enden ohne Fehler — und haben nichts getan.

Warum „es lief” bei einem Agenten weniger aussagt

Ein klassischer Cronjob, der scheitert, sagt das meist auch: ein Exit-Code ungleich null, ein Stacktrace, ein Prozess, der abstürzt. Eine Agenten-Schleife ist darauf gebaut, genau solche Fehler abzufangen und weiterzumachen: Ein Tool-Aufruf scheitert, das Modell entschuldigt sich im nächsten Zug, der Lauf endet, Exit-Code 0. Nichts wurde geschrieben, und nichts sieht falsch aus.

Agenten erben außerdem Fehlerarten, die Cron nie hatte:

• Rate-Limits und Ausgabenlimits. Ein 429-Sturm oder ein erschöpftes Monatsbudget beendet den heutigen Lauf still — und den morgigen gleich mit.
• Hängende Aufrufe. Viele LLM-SDKs kommen ohne Request-Timeout aus. Eine festhängende Verbindung, und der Lauf wird nie fertig — nicht fehlgeschlagen, nur still geworden.
• Modell-Drift. Ein Provider gibt eine Modell-ID auf oder ändert ein Antwortformat nach seinem Zeitplan, nicht Ihrem. Der Job bricht, ohne dass Sie etwas deployt haben.

Nichts davon erzeugt eine Logzeile, die um zwei Uhr nachts jemand liest. Genau das ist das Problem, das ein Totmannschalter löst: Er muss nicht wissen, warum der Lauf still wurde — nur, dass er es wurde.

Das Muster

Verlagern Sie die Frage „hat es funktioniert?” weg von dem Prozess, der selbst hängen könnte. Der Agent pingt beim Abschluss eine externe URL; kommt der Ping nicht innerhalb eines erwarteten Zeitfensters an, löst der Schalter aus.

Das Detail, das speziell bei Agenten zählt: Pingen Sie Erfolg erst, nachdem Sie die Ausgabe geprüft haben — nicht schon beim Prozessende.

curl -fsS https://ping.steadycron.com/<ihr-ping-token>/start
python run_agent.py --task nightly-digest && test -s out/digest.md \
  && curl -fsS https://ping.steadycron.com/<ihr-ping-token> \
  || curl -fsS https://ping.steadycron.com/<ihr-ping-token>/fail

test -s out/digest.md ist der ganze Trick — es prüft, dass tatsächlich ein nicht-leeres Artefakt existiert, bevor Erfolg gemeldet wird. Ein Agent, der „erfolgreich” mit einer leeren Ausgabedatei endet, meldet jetzt /fail — das, was tatsächlich passiert ist.

Auch der /start-Ping zählt: Ohne ihn sieht ein hängender Aufruf nur wie ein verspäteter Lauf aus. Mit ihm erscheint ein Lauf, der gestartet ist, aber nie fertig wurde, als hängend — nicht bloß verzögert. Nützlich, wenn die Ursache ein festhängender API-Aufruf ist statt ein Trigger, der nie gefeuert hat.

Ersetzt nicht die Überwachung der Scheduler-Ebene

Ein ausbleibender Ping sagt Ihnen, dass der Agent kein gültiges Ergebnis produziert hat — nicht, ob die Ursache der Agent selbst war oder das, was ihn ausgelöst hat. Wenn gar nichts den Prozess gestartet hat, liegt der Fehler weiter oben: Prüfen Sie GitHub-Actions-Zeitpläne, Kubernetes-CronJobs oder Vercel Cron auf die Trigger-Ursachen der jeweiligen Plattform. Der Totmannschalter sagt Ihnen, dass in einer Nacht, in der Sie nicht hingeschaut haben, etwas schiefgelaufen ist — die Diagnose, welche Ebene betroffen ist, bedeutet trotzdem: erst den Trigger prüfen, dann den Lauf.

Wo SteadyCron passt

Das ist Heartbeat-Monitoring, angewendet auf Agenten statt auf Cronjobs — kein anderer Mechanismus, nur ein anderer Absender. Setzen Sie eine Kulanzzeit, die zur tatsächlichen Laufzeit passt, pingen Sie /start und /success (erst nach geprüfter Ausgabe) oder /fail, und SteadyCron alarmiert Sie per Slack, E-Mail, Telegram, Discord oder Webhook, sobald kein gültiges Ergebnis mehr ankommt — aus welchem der obigen Gründe auch immer.

Das vollständige Muster — inklusive der Möglichkeit, den Trigger selbst als gehosteten HTTP-Job auf SteadyCron zu verlagern — steht unter Cron-Jobs für KI-Agenten. Debuggen Sie gerade einen Lauf, der bereits verstummt ist? Starten Sie mit Geplanter KI-Agent läuft nicht.

Kostenlos starten — keine Kreditkarte erforderlich.