Cron-Jobs, Batch-Prozesse und zeitgesteuerte Skripte sind das stille Rückgrat vieler IT-Systeme. Sie sichern Datenbanken, synchronisieren Bestände, versenden Reports und führen Wartungsaufgaben durch – zuverlässig, solange niemand hinschaut. Das Problem: Wenn sie aufhören zu laufen, fällt das oft erst auf, wenn der Schaden bereits entstanden ist.
Heartbeat-Monitoring ist die Antwort auf dieses Problem. Statt zu prüfen, ob ein Dienst erreichbar ist, erwartet das Monitoring ein regelmäßiges Signal vom Prozess selbst. Bleibt das Signal aus, schlägt es Alarm.
Das Prinzip: Erwartetes Signal statt aktiver Prüfung
Klassisches Uptime-Monitoring funktioniert reaktiv: Ein externer Checker ruft eine URL auf und misst die Antwort. Das funktioniert gut für HTTP-Dienste, Webseiten und APIs. Für Hintergrundprozesse versagt dieses Modell vollständig – ein Cron-Job hat keine öffentliche URL, die man aufrufen könnte.
Heartbeat-Monitoring dreht das Prinzip um: Der Cron-Job oder Batch-Prozess sendet nach jedem erfolgreichen Lauf einen HTTP-Request an eine eindeutige URL – den Heartbeat-Endpunkt. Das Monitoring-System erwartet dieses Signal in einem definierten Zeitfenster. Kommt kein Signal – weil der Job nicht gelaufen ist, zu lange gedauert hat oder abgestürzt ist – wird ein Alert ausgelöst.
Das klingt einfach, löst aber ein echtes Problem: Stille Ausfälle, die klassisches Monitoring komplett übersieht.
Typische Szenarien, in denen stille Ausfälle unbemerkt bleiben
Stille Ausfälle sind heimtückischer als offensichtliche Fehler. Einige Beispiele aus der Praxis:
Backup schlägt fehl – niemand merkt es
Ein nächtliches Backup-Skript bricht nach einem Systemupdate mit einem nicht abgefangenen Fehler ab. Das Backup-Verzeichnis wächst nicht mehr, aber kein Alarm läuft auf. Drei Wochen später – beim ersten echten Restore-Versuch – stellt das Team fest, dass keine aktuellen Backups existieren. In diesem Moment ist der Schaden bereits eingetreten.
Import-Job läuft nicht mehr durch
Ein Datenimport, der täglich Produktdaten synchronisiert, schlägt nach einer API-Änderung beim Lieferanten fehl. Der Shop zeigt weiterhin Produkte an – nur mit veralteten Daten. Kunden bestellen, die Ware ist nicht vorrätig, Stornierungen häufen sich. Das Problem wäre bei aktivem Heartbeat-Monitoring am nächsten Morgen aufgefallen.
Report-Versand stoppt kommentarlos
Ein wöchentlicher Report-Job, der PDFs per E-Mail verschickt, schlägt nach einer Mailserver-Konfigurationsänderung fehl. Niemand fragt nach, weil solche Reports oft als selbstverständlich gelten. Erst nach mehreren Wochen bemerkt jemand das Ausbleiben.
Datenbereinigung friert ein
Ein Prozess, der täglich veraltete Datenbankeinträge bereinigt, hängt nach einem Datenbankschema-Update in einer Transaktion fest. Die Datenbank wächst unkontrolliert, bis Performance-Probleme auftreten. Der eigentliche Auslöser – der stockende Bereinigungsjob – ist ohne Heartbeat-Monitoring nicht direkt sichtbar.
Heartbeats konfigurieren: Was ein gutes Setup ausmacht
Ein Heartbeat-Check ist schnell eingerichtet. Ein robustes Setup braucht aber mehr Überlegung als nur eine Ping-URL am Ende des Skripts.
Zeitfenster sinnvoll wählen
Das erwartete Intervall sollte dem tatsächlichen Ausführungsintervall entsprechen, plus einem realistischen Puffer für gelegentliche Verzögerungen. Ein stündlicher Job, der manchmal 65 Minuten braucht, sollte ein 75-Minuten-Fenster erhalten – nicht 61 Minuten, das würde konstant Fehlalarme erzeugen. Ein täglich laufender Job mit variablen Laufzeiten bekommt entsprechend mehr Puffer.
Ping erst nach Erfolg senden
Der Heartbeat-Request gehört ans Ende des Skripts – nach der eigentlichen Arbeit, nicht davor. Wenn das Skript vorher abbricht, wird kein Signal gesendet, und das Monitoring schlägt korrekt an. Das ist das gewünschte Verhalten:
#!/bin/bash
# Datenbank-Backup
pg_dump mydb | gzip > /backups/daily_$(date +%Y%m%d).sql.gz
# Nur bei Erfolg (exit code 0) den Heartbeat senden
if [ $? -eq 0 ]; then
curl -fsS --retry 3 "https://monitoring.example.com/heartbeat/abc123" > /dev/null
fiStart- und Ende-Ping kombinieren
Manche Monitoring-Lösungen unterstützen neben dem Ausbleib-Alarm auch einen Laufzeit-Alarm: Ein erster Ping beim Start des Jobs, ein zweiter beim Ende. Wenn der End-Ping ausbleibt oder der Job zu lange braucht, wird ebenfalls ein Alert ausgelöst. Das erkennt hängende Prozesse, die zwar starten, aber nicht vorankommen – ein häufiges Muster bei Deadlocks oder blockierten Ressourcen.
Retry-Logik für den Heartbeat selbst
Der Heartbeat-Request sollte selbst fehlertolerant sein. Ein kurzer Netzwerkausfall sollte nicht dazu führen, dass ein erfolgreich gelaufener Job als ausgefallen gemeldet wird. Ein --retry 3 in curl oder ein gleichwertiger Mechanismus ist empfehlenswert.
Heartbeats in der Praxis: Was zu beachten ist
Abhängigkeit von der Netzwerkverbindung
Wenn das System, auf dem der Job läuft, keine ausgehende Internetverbindung hat, kann kein Heartbeat an einen externen Endpunkt gesendet werden. In solchen Umgebungen – Air-Gapped-Systeme, interne Server ohne Internetzugang – muss ein lokales Monitoring-System oder ein interner Endpunkt verwendet werden. FreshCore bietet Heartbeat-Checks, die per HTTPS-Request ausgelöst werden und sich in entsprechende interne Architekturen integrieren lassen.
Fehlerbehandlung im Skript ist Voraussetzung
Ein schlecht geschriebenes Skript, das den Heartbeat sendet, obwohl die eigentliche Arbeit fehlgeschlagen ist, erzeugt ein falsches Sicherheitsgefühl. Klare Exit-Code-Behandlung und gezielte Fehlerabfangen im Skript sind Voraussetzung dafür, dass Heartbeat-Monitoring seinen Zweck erfüllt.
Inventar der Heartbeats pflegen
Mit der Zeit wächst die Zahl der Heartbeat-Checks. Ein gepflegtes Inventar – welcher Check gehört zu welchem Job, wer ist verantwortlich, was passiert wenn er auslöst – verhindert, dass Alerts im Nichts landen, weil niemand mehr weiß, was der Check überwacht. Sprechende Namen und kurze Beschreibungen im Monitoring-System sind keine Kür.
Heartbeats für KI-Prozesse und autonome Workflows
Mit dem Einzug von KI-Agenten und autonomen Prozessen wird Heartbeat-Monitoring noch wichtiger. Automatisierte Workflows, LLM-gestützte Batch-Jobs und Agenten-Pipelines laufen oft ohne direkten menschlichen Einblick. Wenn ein KI-Agent, der nächtlich Daten analysiert, stillschweigend aufhört zu arbeiten, sind die Konsequenzen genauso real wie beim klassischen Cron-Job – oft sogar schwerwiegender, weil die Abhängigkeiten weniger offensichtlich sind.
Heartbeats für KI-Prozesse haben einige Besonderheiten:
- Laufzeiten sind weniger vorhersehbar – LLM-Aufrufe variieren stärker als Datenbankoperationen
- Kosten-Monitoring sollte parallel laufen – ein Agent, der steckenbleibt und in Endlosschleifen rennt, erzeugt API-Kosten
- Erfolg ist schwieriger zu definieren – war die Ausgabe tatsächlich korrekt, oder nur vorhanden?
- Timeouts müssen konservativer gesetzt werden, um normale Latenzschwankungen abzudecken
Dennoch ist das Grundprinzip identisch: Der Prozess signalisiert selbst, dass er erfolgreich abgeschlossen hat. Bleibt das Signal aus, schlägt das Monitoring an.
Integration in bestehende Monitoring-Stacks
Heartbeat-Monitoring ergänzt andere Monitoring-Formen, ersetzt sie aber nicht. Ein sinnvoller Stack kombiniert:
- Heartbeats für Batch-Jobs, Cron-Skripte und autonome Prozesse
- HTTP-Checks für APIs, Webdienste und öffentliche Endpunkte
- Server-Monitoring für CPU, RAM, Disk und Netzwerk der unterliegenden Infrastruktur
- Log-Monitoring für Fehlermuster in Applikations- und Systemlogs
In FreshCore lassen sich Heartbeat-Checks direkt neben klassischen HTTP-Monitoren, Servern und Domain-Checks verwalten. Alerts aus allen Check-Typen landen über Notification-Handler in denselben Kanälen – Slack, E-Mail, SMS oder Webhook – und bieten so ein einheitliches Bild des Systemzustands.
Fazit
Heartbeat-Monitoring schließt eine echte Lücke im klassischen Monitoring-Stack. Wer nur auf HTTP-Checks setzt, übersieht stille Ausfälle von Batch-Prozessen, die oft kritische Aufgaben übernehmen. Die Implementierung ist einfach – ein HTTP-Request am Ende eines erfolgreichen Runs – aber die Auswirkung ist erheblich: Ausfälle werden erkannt, bevor sie zum Problem werden. Für Teams, die ihre Monitoring-Abdeckung verbessern wollen, ist Heartbeat-Monitoring ein konkreter, praxisnaher nächster Schritt.
Bildquelle: Pexels / Brett Sayles
Quellen: Healthchecks.io-Dokumentation; Cronitor-Dokumentation; Google Site Reliability Engineering (O'Reilly); FreshCore Heartbeat-Dokumentation.
