Cronjob-Überwachung: Push, wenn ein Job nicht läuft

Ein Cronjob, der fehlschlägt, kann dir Bescheid geben: Die Cron-Anleitung schickt einen Push, wenn ein Job mit einem Fehler endet. Ein Job, der gar nicht erst läuft, kann das nicht. Die Crontab-Zeile ist beim Serverumzug verloren gegangen, die Maschine ist aus, der Cron-Dienst steht, oder der Job hängt und wird nie fertig. Nichts schlägt fehl, also wird nichts gesendet, und du merkst es erst an dem Tag, an dem du das Backup von letzter Nacht brauchst.

Ein Lebenszeichen (englisch Heartbeat) dreht das um, deshalb spricht man auch von einem Totmannschalter. Der Job ruft bei jedem Lauf eine URL auf. Honk weiß, wie oft dieser Aufruf kommen soll, und wenn er ausbleibt, öffnet Honk ein Problem und meldet sich auf deinem iPhone, deiner Apple Watch oder im Browser. Der nächste Aufruf schließt es wieder.

So funktioniert ein Lebenszeichen

• Du legst ein Intervall fest: wie oft ein Lebenszeichen kommen soll, von 1 Minute bis 1 Woche.
• Und eine Toleranz: wie viel später es kommen darf, bevor Honk es als überfällig wertet, standardmäßig 5 Minuten. Die Frist endet beim letzten Lebenszeichen plus Intervall plus Toleranz.
• Jedes Lebenszeichen hat eine geheime URL, https://honk-honk.app/hb/…. Jede GET-, POST- oder HEAD-Anfrage an diese URL ist ein Lebenszeichen, ganz ohne Schlüssel oder Header.
• Läuft die Frist ab, öffnet Honk ein Problem im Projekt, ein Langes Hupen, wenn du keine andere Stufe wählst. Der Titel lautet „Nächtliches Backup ist überfällig“, der Text „Kein Signal seit 2026-10-14 03:12 UTC. Erwartet alle 1 Tg. (+5 Min. Toleranz).“ Honk prüft mindestens einmal pro Minute.
• Ein Ausfall, ein Problem. Solange der Job schweigt, kommt nichts mehr dazu: kein neuer Push jede Minute.
• Das nächste Lebenszeichen schließt es mit einer Entwarnung, „Nächtliches Backup ist wieder da“, die wie jede andere als Push ankommt.

Das Problem ist ein ganz normales Honk-Ereignis in der Gruppe heartbeat/<slug>. Ruhezeiten, Stummschaltungen, Live-Aktivitäten und deine Regeln gelten dafür wie für alles andere. Ein neues Lebenszeichen wartet auf seinen ersten Aufruf und kann vorher nicht überfällig werden.

Voraussetzungen

• Ein Honk-Konto und ein Projekt. Honk gibt es vorerst nur auf Einladung. Noch kein Konto? Dann kannst du Zugang anfragen.
• Das Recht, das Projekt zu verwalten. Inhaber und Admins des Workspaces haben es.
• Platz für ein weiteres Lebenszeichen: Ein Workspace kann 2 im Tarif Free haben, 20 in Pro und 100 in Team (Tarife).
• curl auf dem Rechner, auf dem der Job läuft. Das ist auf fast jedem Server installiert.

1. Das Lebenszeichen anlegen

Öffne in der Web-App das Projekt, dann Verbindungen, und wähle Neues Lebenszeichen:

• Name: was im Push stehen soll, etwa „Nächtliches Backup“.
• Erwartetes Intervall: 5 Minuten, 15 Minuten, 1 Stunde, 1 Tag, 1 Woche oder mit Eigenes eine beliebige Zahl von Minuten.
• Toleranz: keine, 1, 5 oder 15 Minuten oder 1 Stunde.
• Stufe bei Verspätung: standardmäßig Langes Hupen, für die Jobs, auf die es am meisten ankommt, Dauerhupen.

Speichere, öffne Einrichten und kopiere die Lebenszeichen-URL. Wer die URL kennt, kann Lebenszeichen senden, also behandle sie wie ein Passwort. Gerät sie in falsche Hände, erzeugst du mit Neue URL eine neue, und die alte funktioniert sofort nicht mehr.

2. Nach jedem Lauf ein Lebenszeichen senden

Häng den Aufruf mit && an den Job an, damit nur ein erfolgreicher Lauf ein Lebenszeichen sendet:

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

-fsS hält curl still, solange nichts schiefgeht, -m 10 gibt nach 10 Sekunden auf, und --retry 3 überbrückt eine kurze Netzwerkstörung. Schlägt der Job fehl, kommt kein Lebenszeichen, und Honk meldet sich, sobald die Toleranz abgelaufen ist.

Die Frist zählt ab dem letzten Lebenszeichen. Die Toleranz muss also nur abdecken, wie stark die Laufzeit des Jobs schwankt. Dauert das Backup manchmal 20 Minuten länger als sonst, gib ihm mindestens so viel Toleranz.

3. Einen Fehler sofort melden

Bei einem nächtlichen Job reicht es, auf die Frist zu warten. Willst du von einem Fehler erfahren, sobald er passiert, ruf die URL mit /fail auf, wenn der Job fehlschlägt. Text im Body, bis zu 1 KiB, wird zur Nachricht:

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null || curl -fsS -m 10 --retry 3 --data-raw "pg_dump failed on $(hostname)" https://honk-honk.app/hb/…/fail > /dev/null

Honk öffnet das Problem sofort: „Nächtliches Backup hat einen Fehler gemeldet“. Das nächste erfolgreiche Lebenszeichen schließt es wie gewohnt.

Meldet der Job seine Fehler schon mit dem Wrapper honk-cron aus der Cron-Anleitung, behalte ihn und lass das Lebenszeichen nur darauf achten, ob der Job überhaupt läuft. Sende es nach jedem Lauf, ob erfolgreich oder nicht, mit ; statt &&:

0 3 * * * /usr/local/bin/honk-cron db/backup pg_dump -f /backup/app.sql app; curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

Der Wrapper sagt dir, dass der Job fehlgeschlagen ist, samt Ausgabe. Das Lebenszeichen sagt dir, dass er gar nicht gelaufen ist.

Worker, Apps und systemd

Alles, was eine HTTP-Anfrage stellen kann, kann ein Lebenszeichen senden: ein Queue-Worker nach jedem Stapel, ein Skript in jeder Sprache oder ein systemd-Dienst. Der Bereich Einrichten in der Web-App hat fertige Zeilen für die Crontab und für OnSuccess= und OnFailure= in systemd. Honk zählt höchstens ein Lebenszeichen alle 10 Sekunden; weitere Aufrufe bekommen eine Antwort, werden aber ignoriert.

Code, der schon einen Ingest-Schlüssel hat, kann statt der URL die API nutzen. Das Lebenszeichen entsteht beim ersten Aufruf, ein Worker kann sich sein eigenes also selbst einrichten:

curl -fsS -m 10 --retry 3 https://honk-honk.app/v1/heartbeats/check-in \
  -H "Authorization: Bearer $HONK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"slug":"queue-worker","name":"Queue worker","interval_seconds":300,"grace_seconds":60}'

Der slug benennt das Lebenszeichen im Projekt des Schlüssels. Spätere Aufrufe können Name, Intervall und Toleranz ändern; Stufe und Pause stellst du in der Web-App ein. Um einen Fehler zu melden, sende "status":"fail" mit einer message.

Wochenenden, Wartung und Pausen

Honk erwartet Lebenszeichen in einem festen Intervall und liest keine Cron-Ausdrücke. Für einen Job, der nur werktags läuft, stellst du das Intervall entweder auf die längste Lücke (3 Tage, von Freitag bis Montag) oder ergänzt eine Crontab-Zeile, die samstags und sonntags ein Lebenszeichen sendet.

Vor einer Wartung wählst du Pausieren. Ein pausiertes Lebenszeichen wird nicht überwacht, und das Pausieren schließt ein offenes Problem. Fortsetzen startet die Uhr ab diesem Moment neu. Auch das Löschen eines Lebenszeichens schließt sein offenes Problem.

Lebenszeichen und Fehlermeldungen

Beide beantworten unterschiedliche Fragen, und ein wichtiger Job verdient beides:

• Die Cron-Anleitung sagt dir, dass der Job gelaufen und fehlgeschlagen ist, mit Exit-Code und Ausgabe.
• Ein Lebenszeichen sagt dir, dass der Job nicht gelaufen oder nie fertig geworden ist, und wann er sich zuletzt gemeldet hat.

Wenn du Healthchecks.io kennst

Es ist dasselbe Prinzip: eine URL pro Job, ein Intervall (dort Period) und eine Toleranz (Grace Time). Healthchecks.io kann außerdem Cron-Ausdrücken und systemd-OnCalendar=-Zeitplänen folgen und ist Open Source, du kannst es also selbst betreiben. Honk hat keine Cron-Ausdrücke und keine Version zum Selbsthosten. Dafür landet ein verstummter Job im selben Posteingang, mit denselben Push-Regeln, wie alles andere, was du betreibst: ein Push pro Ausfall, Entwarnung, wenn der Job wieder läuft, Ruhezeiten, Live-Aktivitäten und deine Apple Watch.