Überwachung von Cronjobs

Problem mit geplanten Aufgaben

Ein grausames Merkmal von Crons ist, dass sie bei Ausfall keinerlei Meldung machen. Die Webanwendung verarbeitet weiter Anfragen, die Startseite sieht OK aus, das Monitoring steht auf Grün – aber irgendwo auf dem Server ist das nächtliche Backup seit zwei Wochen nicht mehr gelaufen. Der Queue-Worker ist nach dem Deploy abgestürzt, die liegengebliebenen Jobs stapeln sich. Die stündliche Synchronisation verliert leise Zeilen wegen eines Berechtigungsproblems. Man erfährt davon erst, wenn irgendwo downstream endlich etwas ausfällt – in der Regel genau dann, wenn man es am dringendsten braucht. Das Data-Team will einen Export, der Support eine E-Mail-Warteschlange, Ops das Backup. Dann ist es meist zu spät.

Standardmäßiges Uptime-Monitoring erkennt das nicht, weil es nichts zu pingen gibt. Cron veröffentlicht keinen HTTP-Endpoint, öffnet keinen Port, startet keinen Server. Er wird ausgeführt, beendet sich, fertig. Wenn er nicht mehr läuft – gibt es keinerlei Signal für seine Abwesenheit, bis man aktiv sucht.

Gegenmuster: Heartbeat-Monitoring

Heartbeat-Monitoring (auch "Dead Man's Switch" oder "Cron-Monitoring" genannt) dreht die Richtung um. Statt wir prüfen deinen Service, meldet sich dein Service bei uns. Du fügst eine Zeile zu deinem Cron hinzu – ein curl auf eine von uns generierte, eindeutige URL – und diese URL speichert bei jedem Aufruf einen Timestamp. Wir überwachen die Abwesenheit dieser Pings. Wenn die URL im erwarteten Intervall (plus Toleranz) nicht kontaktiert wird, wird das als verpasster Lauf gewertet und es wird ein Alarm ausgelöst.

Das Modell ist einfach, zuverlässig und unabhängig von der Programmiersprache. Alles, was einen HTTP-Request absetzen kann, lässt sich integrieren. Bash per curl, Python per requests, Node per fetch, PHP per curl_init, Task Scheduler auf Windows via Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – egal was. Ohne SDK, ohne Agent, ohne Daemon-Installation.

Konfigurationsanleitung

In DiagnoSEO Uptime Monitoring klicke auf "Monitor hinzufügen", wähle den Typ "Heartbeat / Cron". Das Tool generiert eine eindeutige URL mit Token – etwa so: https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Lege das erwartete Intervall fest (wie oft der Job läuft, in Minuten) und die Toleranz (wie viel Verspätung OK ist, bevor wir Alarm schlagen). Speichere ab.

Nun passe deinen Cron so an, dass er die URL nach jedem erfolgreichen Lauf pingt. Drei Varianten je nach Umgebung:

# Bash cron – ping nur bei Erfolg
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Oder wenn teilweiser Erfolg in Ordnung ist
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Ab diesem Punkt sendet jeder erfolgreiche Lauf einen Ping an uns und wir speichern den Timestamp. Wenn wir innerhalb von Intervall + Toleranz Minuten keinen Ping empfangen, wird ein Incident eröffnet und Benachrichtigungen laufen über alle aktivierten Kanäle: Email, Telegram, Slack, Discord, SMS.

Intervall und Toleranz wählen

Das Intervall sollte genau zum Zeitplan des Jobs passen. Nächtliches Backup um 3:00 Uhr – Intervall 1440 Minuten (24h). Stündliche Synchronisation – 60. Worker, der alle 5 min pollt – 5.

Die Toleranz gleicht natürliches Jitter aus. Crons laufen nicht wirklich auf die Nanosekunde – sie werden in die Warteschlange gestellt, warten auf das Ende des letzten Laufs, machen temporäre Pausen bei kleineren Fehlern. Ein 24-Stunden-Job mit 1 Stunde Toleranz gibt einen komfortablen Puffer ohne Alarmverzögerung. Ein Polling-Worker alle 5 Minuten mit 2 Minuten Toleranz erkennt echte Ausfälle schnell, ohne Fehlalarme bei 30-Sekunden-Schluckauf. Generell: Setze die Toleranz auf 10–50 % des Intervalls, je nachdem, wie sehr der Job "zappelt".

Empfohlene Muster

• Ping nur bei Erfolg. Verwende && in Bash – ein fehlgeschlagener Lauf schickt keinen Ping. Wir erkennen das Fehlen und alarmieren.
• Ping nach jeder Iteration der Schleife. Bei langlaufenden Workern pinge nach jeder erfolgreichen Arbeitseinheit innerhalb der Schleife, nicht am Ende. So werden eingefrorene Worker auch während des Laufs erkannt.
• Ein Heartbeat pro logischem Job, nicht pro Skript. Wenn drei Skripte gemeinsam eine nächtliche Pipeline bilden, pinge nur einmal am Ende der Kette. Das gibt ein klares Signal "lebt die Pipeline".
• Kombinieren mit Logs. Heartbeat signalisiert, dass der Job gestartet wurde. Die Logdateien zeigen, was ausgeführt wurde. Zusammen ergibt das das Gesamtbild.

Was passiert, wenn ein Heartbeat ausbleibt?

Ein Incident wird zum Zeitpunkt des Fristablaufs eröffnet. Das Dashboard zeigt den Monitor in rot mit dem Fehler "Kein Heartbeat seit X Minuten". Benachrichtigungen werden über alle aktivierten Kanäle verschickt. Wenn ein frischer Heartbeat eintrifft, schaltet der Monitor automatisch auf up – wird als up markiert, der Incident wird geschlossen und (sofern Recovery-Alerts aktiviert sind) erhältst du eine Benachrichtigung "back online".

All das läuft wie bei anderen Monitoren: Heatmap, Uptime-Prozent, Verlauf, Tags, Suche, Export. Im Dashboard ist ein Heartbeat-Monitor einfach nur eine weitere Zeile, sortier- und filterbar neben HTTP-, ping-, Port- und API-Monitoren.

Checkliste

Monitor hinzufügen → Typ Heartbeat → generierte URL kopieren → zum Cron / Worker / Scheduler hinzufügen → Intervall und Toleranz einstellen → speichern → fertig. Ab jetzt erfährst du sekundenschnell, wenn ein geplantes Task ausfällt – was langfristig zu den wichtigsten Monitoring-Entscheidungen gehört, die du treffen kannst.

Häufig gestellte Fragen

• Was ist Heartbeat / Cron-Job-Monitoring?

  Umgekehrtes Monitoring — dein geplanter Task pingt unsere URL, sobald er erfolgreich läuft. Hören wir im erwarteten Zeitfenster nichts, schlagen wir Alarm. Das löst das Problem lautloser Ausfälle: Ein kaputter Cron-Job erzeugt keinen Fehler und löst keinen klassischen Uptime-Alert aus.

• Wie integriere ich die Heartbeat-URL in meinen Cron?

  Füge curl -fsS <heartbeat_url> ans Ende der Cron-Zeile an. Schlägt der Befehl davor fehl, wird curl nicht ausgeführt und der Heartbeat entfällt. Alternativ ping am Anfang und am Ende mit unterschiedlichen Pfaden – das gibt jeweils separate Signale "started" und "completed".

• Welchen Grace-Period sollte ich wählen?

  Etwa das 2-3fache der typischen Ausführungszeit des Jobs. Wenn dein tägliches Backup 30 Minuten dauert, setze den Grace-Period auf 90 Minuten – damit werden Verzögerungen berücksichtigt, ohne Fehlalarme. Bei Jobs mit variabler Laufzeit großzügig setzen und das Dashboard nutzen, um Ausreißer zu erkennen.

• Kann ich Cron-Jobs überwachen, die stündlich laufen?

  Ja – stelle das Intervall entsprechend ein (z.B. erwartete 60 Minuten mit 15 Minuten Grace). Der Monitor erwartet mindestens alle 75 Minuten einen Ping. Wenn dein Task öfters läuft (z.B. alle 5 Minuten), funktioniert die Heartbeat-URL genauso – passe einfach das Intervall an.

• Funktioniert Heartbeat-Monitoring auch mit AWS Lambda / serverless?

  Ja. Füge einen ausgehenden HTTP-Call zur Heartbeat-URL am Ende der Lambda-Funktion hinzu. Der Monitor behandelt das genauso wie einen Cron-Heartbeat – gleicher Alarmierungsprozess, gleiche Toleranzzeit. Praktisch für geplante Lambdas, bei denen CloudWatch-Alarme stille Fehlschläge nicht erkennen.