Ein Backup-Job läuft täglich um 2 Uhr morgens. Drei Monate lang lief er einwandfrei. Dann hörte er – aus einem scheinbar harmlosen Grund – einfach auf zu laufen. Kein Fehler. Kein Alarm. Keine Benachrichtigung. Erst als die erste echte Wiederherstellung nötig war, fiel auf, dass die letzten Backups nicht existierten. Dieses Szenario ist keine Seltenheit – es ist einer der häufigsten stillen Ausfälle in IT-Systemen. Und Heartbeat-Monitoring ist die Lösung dafür.
Was ist Heartbeat-Monitoring?
Klassisches Uptime-Monitoring prüft, ob ein Dienst erreichbar ist: Antwortet der Server? Gibt die API den richtigen HTTP-Status zurück? Das funktioniert gut für sichtbare Dienste. Hintergrundprozesse hingegen haben keine externe Schnittstelle, die man abfragen könnte. Cronjobs, Batch-Pipelines, Datenbank-Wartungsroutinen, Bereinigungsläufe und Backup-Scripts arbeiten still im Hintergrund – und fallen ebenso still aus, wenn etwas schiefläuft.
Heartbeat-Monitoring dreht das Prinzip um. Statt von außen zu prüfen, ob etwas läuft, sendet der Prozess selbst nach erfolgreichem Abschluss ein Signal an eine externe Stelle. Bleibt dieses Signal aus, schlägt das System Alarm. Das Konzept ist einfach, aber wirkungsvoll: Ein Prozess schickt nach jeder erfolgreichen Ausführung einen HTTP-Request an eine Heartbeat-URL. Wenn das Signal innerhalb des erwarteten Zeitfensters ausbleibt, wird eine Benachrichtigung ausgelöst.
Welche Prozesse sollte man überwachen?
Die Liste ist länger als die meisten Teams vermuten. Typische Kandidaten für Heartbeat-Monitoring sind:
- Backup-Jobs: Datenbankbackups, Filesystem-Snapshots, Off-Site-Synchronisierungen
- Datenimporte und ETL-Pipelines: Jobs, die Daten aus externen Quellen laden und verarbeiten
- Bereinigungsroutinen: Logs löschen, temporäre Dateien aufräumen, alte Datenbankeinträge archivieren
- Zertifikats- und Token-Erneuerungen: Automatische Renewal-Scripts für SSL-Zertifikate oder API-Tokens
- Aggregationsläufe: Statistiken berechnen, Reports erstellen, Dashboards befüllen
- E-Mail- und Benachrichtigungsjobs: Newsletter-Versand, tägliche Digest-Mails, geplante Benachrichtigungen
- Monitoring-Agenten selbst: Auch Monitoring-Skripte können ausfallen – ein Heartbeat für den Collector ist kein Luxus.
Wie Heartbeat-Monitoring technisch funktioniert
Die Implementierung ist im Kern einfach. Ein Heartbeat-Monitor wartet auf ein eingehendes Signal in einem konfigurierten Zeitfenster. Bleibt das Signal aus, wird der Alarm ausgelöst. Das Zeitfenster wird als Kombination aus Intervall und Grace-Period konfiguriert: Das Intervall gibt an, wie oft das Signal erwartet wird. Die Grace-Period definiert, wie lange nach dem erwarteten Zeitpunkt noch gewartet wird, bevor der Alarm greift.
In der Praxis sieht die Integration in einen Cronjob so aus:
- Der Job führt seine eigentliche Aufgabe durch.
- Bei Erfolg sendet er einen HTTP-GET oder HTTP-POST an die Heartbeat-URL.
- Das Monitoring-System registriert das Signal und setzt den Timer zurück.
- Wenn der Timer abläuft, ohne dass ein neues Signal eingeht, wird eine Benachrichtigung ausgelöst.
Der entscheidende Punkt: Das Signal wird nur bei Erfolg gesendet. Schlägt der Job fehl oder wird er gar nicht erst gestartet, bleibt das Signal aus – und das Monitoring reagiert.
Stille Fehler sind die gefährlichsten
Sichtbare Fehler sind unangenehm, aber handhabbar. Ein Server, der nicht antwortet, triggert sofort einen Alert. Ein Cronjob, der lautlos aufhört zu laufen, tut das nicht. Diese stillen Fehler sind besonders tückisch, weil sie sich über lange Zeit unbemerkt aufstauen können. Wenn ein Backup-Job drei Monate lang ausfällt, ist die Lage im Ernstfall deutlich schlechter als wenn er gestern ausgefallen wäre.
Ein Prozess, der ohne Heartbeat läuft, ist kein überwachter Prozess – er ist ein Prozess, von dem man hofft, dass er läuft.
Heartbeat-Monitoring in FreshCore einrichten
FreshCore bietet Heartbeat-Monitore als eigenständigen Monitor-Typ an. Nach dem Anlegen eines Heartbeat-Monitors erhält man eine einzigartige URL, an die der überwachte Prozess sein Signal senden soll. Intervall und Grace-Period lassen sich frei konfigurieren – von minütlichen Prüfungen bis zu täglichen oder wöchentlichen Batch-Jobs. Statusseiten und Notification-Handler können direkt an den Monitor gebunden werden, sodass Teams und Dienste automatisch informiert werden, wenn ein Signal ausbleibt.
Das Einrichten ist ohne Infrastrukturaufwand möglich: Es gibt keine Agenten, keine Firewall-Freigaben, keine Inbound-Verbindungen. Der Prozess sendet nur ausgehende Requests – das funktioniert überall, wo ein HTTP-Request möglich ist.
Häufige Fallstricke und wie man sie vermeidet
Signal auch bei Fehlern senden
Ein klassischer Fehler ist, das Heartbeat-Signal am Anfang des Scripts zu senden statt am Ende. So meldet der Job „ich habe angefangen" – aber nicht „ich habe erfolgreich abgeschlossen". Das Signal sollte immer erst nach erfolgreichem Abschluss gesendet werden. Bei kritischen Jobs empfiehlt sich zusätzlich eine explizite Prüfung des Ergebnisses vor dem Signal.
Grace-Period realistisch setzen
Zu kurze Grace-Periods führen zu Fehlalarmen bei normalen Schwankungen. Ein Backup-Job, der manchmal 10 Minuten dauert und manchmal 40, braucht eine Grace-Period, die das abdeckt – ohne dabei echte Ausfälle zu verschleieren. Eine Faustregel: Grace-Period mindestens so lang wie die maximale normale Laufzeit des Jobs.
Mehrere unabhängige Prozesse nicht bündeln
Wenn ein Script mehrere Aufgaben erledigt und nur ein gemeinsames Heartbeat-Signal sendet, ist bei einem Alarm unklar, welche Aufgabe gescheitert ist. Besser: Pro logische Aufgabe ein eigener Heartbeat. Das macht Diagnosen schneller und präziser.
Fazit
Heartbeat-Monitoring ist eine der einfachsten Maßnahmen mit dem höchsten Nutzen im IT-Monitoring-Portfolio. Es braucht keine aufwändige Infrastruktur, keine Agenten und keinen großen Einrichtungsaufwand. Es schließt genau die Lücke, die klassisches Availability-Monitoring nicht sieht: den stillen Ausfall von Prozessen, die eigentlich laufen sollten. Wer regelmäßige Jobs betreibt und noch keine Heartbeat-Überwachung hat, nimmt ein unnötiges Risiko in Kauf.
Bildquelle: Serverrack mit Netzwerkkabeln. Bild: EFTA / Wikimedia Commons, CC BY 4.0.
