Cronjobs überwachen: So merkst du, wenn Jobs still sterben.
Stand 11. Juli 2026 · 6 Min. Lesezeit
Ein ausgefallener Webserver fällt schnell auf. Ein ausgefallenes Backup fällt auf, wenn du es brauchst, und das ist der teuerste Zeitpunkt. Cronjobs scheitern leise: kein Fehler auf der Website, kein Alarm, einfach Stille. Das Heartbeat-Prinzip macht diese Stille hörbar.
Inhalt
Warum Cronjobs leise sterben
Die typischen Ursachen sind unspektakulär: eine volle Festplatte, abgelaufene Zugangsdaten, eine gelöschte oder auskommentierte Crontab-Zeile, ein Server-Umzug, bei dem der Job nicht mitgezogen wurde, oder ein Skript, das seit dem letzten Update mit Fehlercode abbricht.
Klassisches Website-Monitoring sieht davon nichts, denn die Website läuft ja. Du brauchst eine Überwachung, die anschlägt, wenn etwas NICHT passiert.
Das Heartbeat-Prinzip
Ein Heartbeat-Monitor dreht die Prüfrichtung um: Dein Job meldet sich nach jedem erfolgreichen Lauf mit einem kurzen HTTP-Request an einer eindeutigen Ping-URL. Der Monitoring-Dienst erwartet diese Meldung in einem definierten Rhythmus, zum Beispiel täglich mit etwas Toleranz (Grace-Zeit). Bleibt sie aus, wirst du alarmiert.
Der Charme daran: Es ist egal, WARUM der Job nicht lief. Ob Crontab weg, Server aus oder Skript kaputt, die ausbleibende Meldung fängt alle Ursachen mit einem einzigen Mechanismus.
Einrichtung in einer Zeile
Am Ende deines Cronjobs hängst du einen curl-Aufruf an die Ping-URL an. Wichtig: mit && verketten, damit nur bei ERFOLG gepingt wird:
0 3 * * * /usr/local/bin/backup.sh && curl -fsS --retry 3 https://uptime.clesk.space/ping/DEIN-TOKEN >/dev/nullDie typischen Fallen
An diesen Details scheitern Heartbeat-Setups in der Praxis:
- ; statt &&: Mit einem Semikolon pingt der Job auch bei Fehlschlag, das Monitoring meldet dann fälschlich "alles gut". Immer && verwenden.
- Grace-Zeit zu knapp: Ein Backup, das mal 20 Minuten länger braucht, ist kein Ausfall. Grace-Zeit großzügiger wählen als die normale Schwankung.
- Zeitzonen: Cron läuft in der Zeitzone des Servers, dein Monitoring rechnet meist in UTC. Bei einem täglichen 3-Uhr-Job den erwarteten Rhythmus entsprechend setzen.
- curl-Fehler verschlucken: -fsS sorgt dafür, dass curl bei HTTP-Fehlern einen Fehlercode liefert und still bleibt, solange alles klappt; --retry 3 überbrückt kurze Netz-Aussetzer.
- "Job läuft, tut aber nichts": Der Heartbeat bestätigt nur, DASS der Job durchlief. Ob das Backup brauchbar ist, prüfst du zusätzlich, z. B. per Restore-Test oder Größen-Check im Skript, bevor gepingt wird.
Welche Jobs einen Heartbeat verdienen
Als Faustregel: alles, dessen stilles Scheitern dich Geld oder Daten kostet.
- Backups (Datenbank und Dateien), der Klassiker
- Importe/Exporte und Schnittstellen-Syncs (Warenwirtschaft, Feeds, Newsletter-Listen)
- Rechnungs- und Report-Läufe
- Zertifikats- und Renewal-Jobs (certbot renew)
- Queue-Worker und Aufräum-Jobs, die sonst niemand ansieht
Häufige Fragen
Was, wenn mein Job unterschiedlich lange läuft?
Dafür ist die Grace-Zeit da: Erwartest du den Ping täglich, gib z. B. 6 Stunden Toleranz. Alarm gibt es erst, wenn Rhythmus plus Toleranz überschritten sind.
Funktioniert das auch mit systemd-Timern oder Windows-Aufgabenplanung?
Ja. Entscheidend ist nur, dass nach erfolgreichem Lauf ein HTTP-Request an die Ping-URL abgesetzt wird, das geht aus jedem Scheduler, jeder Sprache und jedem CI-System.
Wie viele Heartbeat-Monitore brauche ich?
Einen pro Job, den du vermissen würdest. Bei Clesk Uptime sind Heartbeats im Pro-Plan enthalten und in zwei Minuten angelegt: Name, erwarteter Rhythmus, Grace-Zeit, fertig ist die Ping-URL.
Dein Backup verdient einen Wachhund.
Heartbeat-Monitor anlegen, curl-Zeile anhängen, ruhig schlafen. In Pro enthalten.
Kostenlos überwachen