Um einen Cron-Job zu überwachen, geben Sie ihm einen Heartbeat: eine eindeutige URL, die der Job jedes Mal aufruft, wenn er fertig ist. Ein Monitoring-Dienst erwartet diesen Aufruf in einem regelmäßigen Intervall. Kommt er nicht rechtzeitig an, weil der Job nicht gelaufen, abgestürzt oder hängen geblieben ist, erhalten Sie einen Alarm. Dafür reicht eine zusätzliche Zeile in Ihrer Crontab.
Dieser Leitfaden zeigt, wie Heartbeats funktionieren, wie Sie einen einrichten und wie Sie die richtigen Einstellungen wählen.
Warum Cron-Jobs eigenes Monitoring brauchen
Cron startet Befehle zuverlässig und schweigt darüber, was danach passiert. Scheitert ein Backup-Skript um 02:00 Uhr, geht nichts sichtbar kaputt. Die Website bleibt erreichbar, die Uptime-Prüfungen bleiben grün. Sie merken es Wochen später, wenn Sie das Backup brauchen und es nicht da ist.
Typische lautlose Fehler:
Der Server war zum geplanten Zeitpunkt ausgefallen oder startete gerade neu.
Die Crontab wurde bei einem Deployment oder einer Servermigration überschrieben.
Der Befehl scheitert unter Cron, weil PATH oder andere Umgebungsvariablen sich von Ihrer Shell unterscheiden.
Das Skript läuft, hängt aber an einem Lock, einem Netzwerkaufruf oder einer vollen Festplatte.
Zugangsdaten sind abgelaufen, also startet der Job und endet mit einem Fehler, den niemand liest.
Uptime-Monitoring sieht nichts davon, weil nichts Öffentliches kaputtgeht. Ein Heartbeat funktioniert andersherum: Statt dass der Monitor Ihren Job prüft, meldet sich Ihr Job beim Monitor.
So funktioniert ein Heartbeat
Sie legen einen Heartbeat-Monitor an und erhalten eine eindeutige URL.
Sie legen fest, wann der Job laufen soll – als Intervall wie alle 24 Stunden oder als Crontab-Zeitplan des Jobs –, mit etwas Spielraum für langsame Läufe.
Der Job ruft die URL per GET oder POST auf, wenn er fertig ist.
Kommt kein Aufruf rechtzeitig an, wird ein Vorfall eröffnet und Alarme gehen raus.
Sobald der nächste Ping eintrifft, erholt sich der Heartbeat und Sie erhalten eine Entwarnung.
So funktionieren die Cron-Monitore von Uptimecheck. Sie übernehmen den Crontab-Zeitplan in Ihrer Zeitzone, akzeptieren Start- und End-Pings auf einem Monitor, alarmieren, wenn ein Lauf seine maximale Laufzeit überschreitet, und können den Exit-Code und die Ausgabe des Jobs speichern. Alarme gehen per E-Mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, Webhooks und Push-Benachrichtigung aufs Smartphone raus, in jedem Tarif.
Einen Heartbeat in die Crontab einbauen
Angenommen, ein Backup läuft jede Nacht um 02:30 Uhr:
30 2 * * * /usr/local/bin/backup.sh
Hängen Sie den Ping hinter den Job, verknüpft mit &&, damit er nur läuft, wenn das Backup erfolgreich war:
30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Was die curl-Optionen bewirken:
-f lässt curl bei HTTP-Fehlern scheitern, statt sie als Erfolg zu werten.
-s unterdrückt die Ausgabe, und -S zeigt trotzdem Fehler an, wenn etwas schiefgeht.
-m 10 wartet höchstens 10 Sekunden, sodass ein langsames Netz den Job nie blockiert.
–retry 3 wiederholt den Aufruf bei kurzen Netzwerkproblemen.
Ersetzen Sie den Platzhalter durch die genaue URL Ihres Heartbeat-Monitors.
Ping aus einem Skript heraus
Bei längeren Skripten setzen Sie den Ping ans Ende des Skripts selbst, hinter die Schritte, auf die es ankommt:
#!/usr/bin/env bash
set -euo pipefail
pg_dump northwind > /backups/northwind-$(date +%F).sql
gzip /backups/northwind-$(date +%F).sql
curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Mit set -e bricht das Skript beim ersten fehlschlagenden Befehl ab, sodass der Ping nur gesendet wird, wenn alles davor funktioniert hat.
Andere Scheduler
Heartbeats sind nicht auf Cron beschränkt. Alles, was eine HTTP-Anfrage senden kann, kann pingen: systemd-Timer, die Windows-Aufgabenplanung mit PowerShells Invoke-WebRequest, ein Kubernetes-CronJob, eine CI-Pipeline oder eine geplante Funktion in Ihrer Anwendung.
Das Intervall wählen
Das Intervall sollte zum Zeitplan passen: 24 Stunden für einen nächtlichen Job, 1 Stunde für einen stündlichen. Lassen Sie Spielraum für normale Schwankungen in der Laufzeit. Dauert ein Backup normalerweise 20 Minuten, manchmal aber 50, vermeidet eine zusätzliche Stunde Spielraum Fehlalarme, ohne einen echten Fehler lange zu verbergen.
Starten Sie großzügig, beobachten Sie ein, zwei Wochen lang, wie lange die Läufe tatsächlich dauern, und ziehen Sie das Intervall dann an. Akzeptiert Ihr Monitor den Crontab-Ausdruck selbst, wie der von Uptimecheck, fügen Sie den Zeitplan ein und wählen Sie die Zeitzone des Servers. Die erwarteten Zeitpunkte folgen dann exakt dem Zeitplan, und der Spielraum wird zur Kulanzzeit.
Heartbeats im Vergleich zu anderen Ansätzen
Es gibt andere Wege, geplante Jobs zu überwachen, jeder mit Lücken:
E-Mail von Cron. Cron kann die Ausgabe eines Befehls per E-Mail schicken, aber nur, wenn der Job läuft und etwas ausgibt. Startet der Job nie, kommt keine E-Mail. Die meisten dieser E-Mails bleiben ohnehin ungelesen.
Log-Monitoring. Nützlich, um Fehler zu finden, aber ein Job, der nie gelaufen ist, schreibt keine Logzeile, nach der man suchen könnte.
Ergebnisse prüfen. Manche Teams prüfen, ob eine Backup-Datei existiert oder eine Tabelle aktualisiert wurde. Das funktioniert, erfordert aber für jeden Job eigene Prüfungen.
Ein Heartbeat funktioniert für jeden Job gleich und erkennt den Fall, den die anderen übersehen: den Job, der überhaupt nicht gelaufen ist.
Lang laufende Jobs
Bei Jobs, die lange dauern, etwa große Backups oder Datenmigrationen, pingen Sie am Anfang und am Ende. Kommt der Start-Ping an, der End-Ping aber nicht, ist der Job auf halbem Weg hängen geblieben oder abgestürzt. So wissen Sie, wo Sie suchen müssen, bevor Sie auch nur eine Logdatei öffnen.
In Uptimecheck gehen beide Pings an denselben Monitor: Rufen Sie zu Beginn des Jobs die URL mit angehängtem /start auf und am Ende die einfache URL. Die Zeit dazwischen wird als Laufzeit erfasst, und wenn Sie eine maximale Laufzeit festlegen, werden Sie alarmiert, sobald ein Lauf länger dauert.
Welche Jobs einen Heartbeat bekommen sollten
Nicht jeder Job braucht einen. Priorisieren Sie Jobs, deren Ausfall Sie erst später bemerken würden:
Datenbank- und Datei-Backups.
Datenimporte und -exporte, etwa Produktfeeds oder die Synchronisierung mit der Buchhaltung.
Rechnungsläufe, Verlängerungen und Abrechnungsjobs.
Jobs zur Zertifikatserneuerung.
Aufräumjobs, die verhindern, dass eine Festplatte volläuft.
Berichtserstellung, auf die andere angewiesen sind.
Geben Sie jedem Job einen eigenen Heartbeat. Ein gemeinsamer sagt Ihnen, dass etwas nicht gelaufen ist, aber nicht, was.
Fehlersuche bei einem ausgebliebenen Heartbeat
Wenn ein Heartbeat-Alarm eintrifft:
Prüfen Sie, ob Cron den Job gestartet hat. Schauen Sie ins Cron- oder Systemlog.
Führen Sie den Befehl von Hand aus, als derselbe Benutzer, den Cron verwendet, und lesen Sie die Ausgabe.
Prüfen Sie die Umgebung. Verwenden Sie absolute Pfade oder setzen Sie PATH am Anfang der Crontab.
Prüfen Sie die Ressourcen. Eine volle Festplatte oder erschöpfter Arbeitsspeicher stoppt viele Jobs. Server-Monitoring zeigt Festplatte, RAM und Last zum Zeitpunkt des Fehlers.
Prüfen Sie ausgehende Verbindungen. Eine Firewall-Änderung kann den Ping blockieren, auch wenn der Job funktioniert. Ist der Job gelaufen, aber der Ping fehlgeschlagen, steht der Fehler von curl in der Ausgabe des Jobs.
Leiten Sie die Ausgabe des Jobs in eine Logdatei um, damit es immer etwas zu lesen gibt:
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 && curl -fsS -m 10 https://heartbeat.example.com/your-unique-id > /dev/null
Sie können das Ergebnis auch mit dem Ping senden. In Uptimecheck meldet der Exit-Code am Ende der URL (/0 bedeutet Erfolg, alles andere einen Fehler), wie der Job geendet hat, und ein POST-Body wird als Ausgabe des Jobs gespeichert und mit dem Alarm angezeigt. Diese Zeile pingt zum Start, führt den Job aus und meldet seinen Exit-Code und seine Ausgabe:
30 2 * * * curl -fsS -m 10 –retry 3 -o /dev/null https://heartbeat.example.com/your-unique-id/start; /usr/local/bin/backup.sh > /tmp/backup.log 2>&1; curl -fsS -m 10 –retry 3 –data-binary @/tmp/backup.log -o /dev/null https://heartbeat.example.com/your-unique-id/$?
Checkliste für das Monitoring von Cron-Jobs
Listen Sie die wichtigen geplanten Jobs auf, auf jedem Server.
Legen Sie pro Job einen Heartbeat an.
Pingen Sie erst, nachdem die Arbeit erfolgreich war, verknüpft mit && oder am Ende eines set -e-Skripts.
Stellen Sie das Intervall auf den Zeitplan ein, mit Spielraum für langsame Läufe.
Schreiben Sie die Ausgabe des Jobs in eine Datei.
Senden Sie Alarme an einen Kanal, den jemand liest, bei kritischen Jobs auch nachts.
Prüfen Sie den Heartbeat-Verlauf nach Deployments und Servermigrationen.
Zusammenfassung
Cron sagt Ihnen nicht, wenn ein Job scheitert. Ein Heartbeat schon. Eine curl-Zeile pro Job macht aus lautlosen Fehlern Alarme, und der Verlauf zeigt Ihnen genau, wann jeder Job zuletzt gelaufen ist.
Heartbeats sind in jedem Uptimecheck-Tarif enthalten, zusammen mit Uptime-, SSL-, Domain-, DNS- und Server-Monitoring. Testen Sie es 14 Tage kostenlos, ohne Kreditkarte.