Was ist Heartbeat-Monitoring?

Heartbeat-Monitoring funktioniert umgekehrt zum klassischen Uptime-Monitoring. Statt dass ein Tool deinen Server von außen anpingt, sendet deine geplante Aufgabe nach jedem erfolgreichen Lauf selbst einen kurzen Ping an den Monitor. Bleibt dieser Ping innerhalb des erwarteten Intervalls plus einer Grace-Period aus, wird sofort alarmiert. Das ist der zuverlässigste Weg, um zu erkennen, ob ein Cronjob, ein Backup-Script oder ein Background-Worker stillschweigend gestoppt hat — also ohne Fehlermeldung einfach nicht mehr läuft. Ein von außen erreichbarer Endpunkt ist dafür nicht nötig.

Wie überwache ich einen Cronjob mit einem curl-Einzeiler?

Du hängst an das Ende deines Scripts eine einzige HTTP-Anfrage an deine eindeutige Ping-URL an, zum Beispiel: curl -fsS https://foundersdeck.dev/ping/dein-token > /dev/null. Läuft das Script erfolgreich durch, wird der Ping gesendet und der Monitor bleibt grün. Bricht das Script vorher ab oder läuft der Cronjob gar nicht mehr, bleibt der Ping aus und du bekommst nach Ablauf der Grace-Period einen Alert. Es ist kein Agent, kein Daemon und kein SDK nötig — der Einzeiler funktioniert mit jeder Sprache und jeder Plattform, die eine HTTP-Anfrage senden kann.

Warum reicht ein Exit-Code oder eine Log-Zeile nicht zur Überwachung von Cronjobs?

Weil der häufigste Cronjob-Fehler das komplette Ausbleiben der Ausführung ist — und ein Job, der nie startet, schreibt weder eine Log-Zeile noch einen Exit-Code. Ursachen sind ein gelöschter crontab-Eintrag, ein abgestürzter Scheduler, ein vollgelaufenes Dateisystem, abgelaufene Credentials oder ein Server, der nach einem Neustart den Dienst nicht wieder hochgefahren hat. Exit-Codes und Logs erkennen nur Fehler, die während einer tatsächlichen Ausführung passieren. Heartbeat-Monitoring erkennt zusätzlich die stille Abwesenheit — es alarmiert, wenn der erwartete Ping ausbleibt, egal warum.

Kann ich Cronjobs überwachen, die nur wöchentlich oder monatlich laufen?

Ja. Bei Heartbeat-Monitoring legst du das erwartete Intervall selbst fest — von wenigen Minuten bis zu Tagen oder Wochen. Ein wöchentliches Backup bekommt ein Intervall von sieben Tagen plus eine passende Grace-Period, die natürliche Schwankungen in der Laufzeit abfängt. Der Alert wird nur ausgelöst, wenn der Ping tatsächlich ausbleibt, nicht bei geringfügiger Verspätung. Gerade selten laufende Jobs profitieren am meisten von Heartbeat-Monitoring, weil ein monatelanger stiller Ausfall eines Backups sonst erst auffällt, wenn man das Backup dringend braucht.

Welches Heartbeat-Monitoring-Tool ist DSGVO-konform?

Entscheidend ist der Rechtssitz des Anbieters, nicht nur der Serverstandort. Ein US-eingetragenes Tool unterliegt auch mit EU-Rechenzentrum dem US CLOUD Act. FoundersDeck ist ein inhabergeführtes deutsches Unternehmen, hostet ausschließlich bei Netcup in Nürnberg und unterliegt nicht dem CLOUD Act — Heartbeat-Monitoring ist bereits im kostenlosen Tarif enthalten. Quelloffene, selbst gehostete Optionen wie Healthchecks.io geben dir volle Datenkontrolle, verlagern aber den Betriebs- und Wartungsaufwand zu dir. Welche Tools jurisdiktionell wie dastehen, schlüsselt unsere EU SaaS Jurisdiction Database auf.

Cronjob-Monitoring für Indie-Hacker: Heartbeat-Setups von Reddit

Es gibt eine Frage, die in r/selfhosted, r/devops, r/homelab und r/indiehackers immer wieder auftaucht — oft nachdem jemand gerade auf die harte Tour gelernt hat, warum sie wichtig ist: „Wie merke ich, dass mein Cronjob nicht mehr läuft?” Die typische Geschichte dahinter: Ein nächtliches Backup ist seit sechs Wochen still gestorben, niemand hat es bemerkt, und aufgefallen ist es erst, als das Backup gebraucht wurde. Dieser Leitfaden fasst die Antworten aus diesen Threads zusammen und zeigt das Setup, das sich durchgesetzt hat.

Heartbeat-Monitoring ist die Überwachung geplanter Aufgaben durch ein umgekehrtes Signal: Statt dass ein Tool deinen Dienst anpingt, meldet sich die Aufgabe nach jedem erfolgreichen Lauf selbst. Bleibt die Meldung aus, wird alarmiert. Damit lässt sich genau die Fehlerklasse erkennen, an der klassisches Uptime-Monitoring scheitert: der Job, der einfach nicht mehr startet.

Warum klassisches Monitoring Cronjobs nicht abdeckt

Uptime-Monitoring prüft von außen, ob eine URL antwortet. Das funktioniert für Websites und APIs — aber ein Cronjob, ein Backup-Script oder ein Background-Worker hat keine öffentliche URL, die man anpingen könnte. Diese Aufgaben laufen im Verborgenen, und ihr gefährlichster Fehlermodus ist der stille: Sie hören auf zu laufen, ohne dass irgendjemand eine Fehlermeldung sieht.

Die üblichen Verdächtigen aus den Reddit-Threads:

Ein crontab-Eintrag wurde bei einem Deployment versehentlich überschrieben
Der Server wurde neu gestartet und der Dienst kam nicht wieder hoch
Das Dateisystem ist vollgelaufen, das Script bricht vor dem Start ab
Ein abgelaufenes API-Token oder Zertifikat lässt den Job scheitern
Der Scheduler-Prozess (systemd-timer, Worker-Queue) ist abgestürzt

Der gemeinsame Nenner: Ein Job, der nie startet, schreibt keine Log-Zeile und liefert keinen Exit-Code. Deshalb reichen Logs und Exit-Codes allein nicht — sie erkennen nur Fehler während einer Ausführung, nicht deren komplettes Ausbleiben.

Das Heartbeat-Prinzip

Heartbeat-Monitoring dreht die Richtung um. Du legst einen Monitor mit einem erwarteten Intervall an (z. B. „einmal pro Tag”) und bekommst eine eindeutige Ping-URL. Am Ende deines Scripts rufst du diese URL auf. Kommt der Ping regelmäßig, ist alles grün. Bleibt er länger als Intervall plus Grace-Period aus, wird alarmiert.

Der große Vorteil: Es ist agentenlos. Kein Daemon, kein SDK, keine Abhängigkeit — nur eine einzige HTTP-Anfrage. Das funktioniert mit jeder Sprache, jeder Plattform und jeder Infrastruktur, die einen HTTP-Request absetzen kann.

Das Setup: ein curl-Einzeiler

So sieht der von Reddit meistempfohlene Ansatz in der Praxis aus. Du hängst den Ping an das Ende deines Cronjobs — er läuft nur, wenn das Script vorher erfolgreich durchgelaufen ist:

# Tägliches Backup, das sich nach Erfolg meldet
0 3 * * *  /usr/local/bin/backup.sh && curl -fsS https://foundersdeck.dev/ping/dein-token > /dev/null

Oder innerhalb eines Scripts, ganz am Ende:

#!/usr/bin/env bash
set -euo pipefail

pg_dump meinedb | gzip > /backups/db-$(date +%F).sql.gz
rclone copy /backups remote:backups

# Erst hier, nach erfolgreichem Lauf, den Heartbeat senden
curl -fsS https://foundersdeck.dev/ping/dein-token > /dev/null

Die Flags sind bewusst gewählt: -f lässt curl bei HTTP-Fehlern scheitern, -s unterdrückt den Fortschritt, -S zeigt echte Fehler trotzdem an. Durch das && bzw. set -e wird der Ping nur gesendet, wenn die eigentliche Arbeit geklappt hat — bricht das Backup ab, bleibt der Heartbeat aus und du wirst alarmiert.

Grace-Period richtig setzen

Der häufigste Konfigurationsfehler ist eine zu knappe Grace-Period. Aufgaben schwanken in ihrer Laufzeit — ein Backup dauert an manchen Tagen länger, ein Import wartet auf eine langsame API. Die Grace-Period ist der Puffer zwischen „erwartetem” und „tatsächlichem” Alarm.

Faustregel: Setze die Grace-Period auf die längste realistische Laufzeit plus etwas Reserve. Ein Job, der normalerweise 5 Minuten läuft, gelegentlich aber 20, sollte eine Grace-Period von deutlich über 20 Minuten haben — sonst bekommst du Fehlalarme. Bei FoundersDeck ist die Grace-Period pro Monitor frei konfigurierbar, von 1 Minute bis 2 Stunden.

Was Reddit für Cronjob-Monitoring empfiehlt

Für die Heartbeat-/Cron-spezifische Überwachung fallen in den Threads vor allem diese Namen:

Tool	Modell	Kostenlos nutzbar	EU-Datenhoheit
Healthchecks.io	Quelloffen, gehostet + selbst hostbar	✅ Free-Tier / Self-Hosting	⚠️ Bei Self-Hosting ja; gehostet prüfen
Cronitor	Gehostet (US)	⚠️ Begrenzt	❌ US-Gesellschaft
Dead Man's Snitch	Gehostet (US)	⚠️ Begrenzt	❌ US-Gesellschaft
FoundersDeck	Gehostet in Deutschland	✅ Heartbeat im Free-Tier	✅ Nürnberg, kein CLOUD Act

Healthchecks.io ist der Liebling von r/selfhosted, weil es quelloffen ist und selbst gehostet werden kann — volle Datenkontrolle, aber du trägst den Betriebs- und Wartungsaufwand, und es stellt sich dieselbe Frage wie bei jedem Self-Hosting: Wer überwacht den Monitor, wenn dein Server ausfällt? Cronitor und Dead Man’s Snitch sind ausgereifte gehostete Optionen, teilen aber die CLOUD-Act-Exposition aller US-Anbieter.

FoundersDeck deckt Heartbeat-Monitoring bereits im kostenlosen Tarif ab — inklusive E-Mail-Alerts, konfigurierbarer Grace-Period und der Möglichkeit, Heartbeat-Monitore neben deinen Uptime-Monitoren auf einer öffentlichen Status-Seite anzuzeigen. Alles gehostet in Nürnberg, ohne dass Daten die EU verlassen. Die Details stehen auf unserer Seite zum Heartbeat- & Cronjob-Monitoring.

Der EU-Blick: wo landen deine Heartbeat-Daten?

Heartbeat-Daten wirken harmlos — es ist ja nur ein Ping. Tatsächlich verraten sie einiges über deine Infrastruktur: welche Jobs du wann laufen lässt, wie oft, mit welcher Zuverlässigkeit. Für Teams mit DSGVO-Anforderungen gilt hier dieselbe Regel wie beim Uptime-Monitoring: Serverstandort ist nicht gleich Jurisdiktion. Ein US-eingetragenes Tool unterliegt auch mit EU-Rechenzentrum dem US CLOUD Act.

In unserer EU SaaS Jurisdiction Database (eigene Erhebung, 57 Entwickler-Tools in 7 Kategorien, zuletzt verifiziert am 9. Juni 2026) sind 29 von 57 Tools US-eingetragen und 25 direkt dem CLOUD Act ausgesetzt; nur 16 von 57 garantieren echte EU-Datenresidenz. Wenn du ein Tool aus einem Reddit-Thread evaluierst, ist die Datenbank die schnellste Art, seinen Firmensitz und seine CLOUD-Act-Exposition nachzuschlagen, bevor du deine Infrastruktur-Signale dorthin sendest.

Checkliste: Cronjob-Monitoring in 10 Minuten

Liste deine unsichtbaren Aufgaben. Backups, Datenexporte, Cleanup-Jobs, Queue-Worker, Zertifikats-Renewals — alles, was ohne Nutzerinteraktion läuft.
Lege pro Aufgabe einen Heartbeat-Monitor an mit dem erwarteten Intervall.
Setze eine realistische Grace-Period (längste Laufzeit plus Reserve).
Hänge den curl-Einzeiler ans Ende jedes Scripts — nach der eigentlichen Arbeit.
Teste den Ausfall bewusst: Kommentiere einen Cronjob aus und prüfe, ob der Alert wirklich kommt.
Prüfe die Jurisdiktion deines Tools in der EU SaaS Jurisdiction Database.

Fazit

Der teuerste Ausfall ist der, den niemand bemerkt. Cronjobs, Backups und Worker scheitern still — und genau dort setzt Heartbeat-Monitoring an: ein umgekehrtes Signal, ein curl-Einzeiler, sofortige Alerts, wenn der Ping ausbleibt. Reddit empfiehlt für den Self-Hosting-Weg Healthchecks.io; wer eine gehostete, DSGVO-native Lösung ohne Wartungsaufwand will, bekommt Heartbeat-Monitoring bei FoundersDeck schon im Free-Tier.

Kostenlos starten — Heartbeat- und Uptime-Monitoring, eine Status-Seite, keine Kreditkarte. Mehr zum Thema im Heartbeat- & Cronjob-Monitoring-Überblick und im Vergleich der besten Uptime-Monitoring-Tools 2026.

Die Jurisdiktions- und DSGVO-Angaben in diesem Artikel stammen aus der EU SaaS Jurisdiction Database: 57 Entwickler-Tools in 7 Kategorien, zuletzt verifiziert am 9. Juni 2026. Korrekturen willkommen.