Zurück zum Blog

Monitoring von Cron-Jobs und Background-Workern via Heartbeat

· 6 Min. Lesezeit

Kurz gesagt: Klassisches HTTP-Monitoring erkennt nicht, dass Ihr nächtlicher Cron, der Rechnungen versendet oder Daten synchronisiert, gefallen ist. Das Heartbeat-Pattern kehrt die Kommunikationsrichtung um - der Cron meldet sich beim Monitoring, und wenn er nicht zur erwarteten Zeit anruft, bekommen Sie einen Alert.

Kurz gesagt: Klassisches HTTP-Monitoring erkennt nicht, dass Ihr nächtlicher Cron, der Rechnungen versendet oder Daten synchronisiert, gefallen ist. Das Heartbeat-Pattern kehrt die Kommunikationsrichtung um - der Cron meldet sich beim Monitoring, und wenn er nicht zur erwarteten Zeit anruft, bekommen Sie einen Alert.

Das Problem: Background-Tasks ohne HTTP-Endpoint

Ein typisches Backend hat folgende Pfade:

  • Web-Requests (HTTP/HTTPS zum Server) - überwachen Sie mit Uptime-Check.
  • Cron-Jobs (tägliches Backup, monatliche Rechnungserstellung, stündliche Sync) - haben keinen HTTP-Endpoint, externes Monitoring sieht sie nicht.
  • Workers (Celery, BullMQ, Sidekiq), die eine Queue konsumieren - auch ohne HTTP.

Wenn der Cron fällt (Sie ändern crontab und machen einen Tippfehler, der Server hat keinen Disk, eine Environment Variable fehlt, ein Dependency-Upgrade hat den Import zerstört), warnt Sie niemand - bis Sie am Montagmorgen bemerken, dass am Wochenende keine Rechnungen versendet wurden.

Heartbeat-Pattern: Cron pingt das Monitoring

Das Prinzip ist gegenüber normalem Monitoring umgekehrt:

  1. Im Monitoring-Service erstellen Sie einen Heartbeat-Monitor mit erwartetem Intervall (z. B. „alle 60 Minuten").
  2. Sie erhalten eine eindeutige Heartbeat-URL: https://epulz.io/heartbeat/abc123xyz.
  3. In Ihrem Cron-Job rufen Sie am Ende eines erfolgreichen Laufs diese URL auf (HTTP GET oder POST).
  4. Wenn der Ping nicht ankommt zur erwarteten Zeit (+ Grace Period), alarmiert Sie das Monitoring.

Praktisches Beispiel: Bash-Cron

# /etc/crontab
0 3 * * * www-data /usr/local/bin/backup.sh && curl -fsS -m 10 \
  https://epulz.io/heartbeat/abc123xyz > /dev/null

Der Schlüssel ist das && - der Heartbeat wird nur gesendet, wenn backup.sh mit Exit-Code 0 endet. Wenn das Skript fehlschlägt, kommt der Ping nicht, und Sie erhalten innerhalb einer Stunde einen Alert.

Tipp: Für gründlichere Abdeckung fügen Sie auch einen „start"-Heartbeat hinzu:

curl -fsS -m 10 https://epulz.io/heartbeat/abc123xyz/start > /dev/null
/usr/local/bin/backup.sh
EXIT=$?
curl -fsS -m 10 "https://epulz.io/heartbeat/abc123xyz?exit=$EXIT" > /dev/null

Das Monitoring unterscheidet dann „gestartet und nicht beendet" (Skript ist eingefroren) von „gar nicht gestartet" (der Cron-Job lief nicht).

Python: requests + try/except

import os, requests
HEARTBEAT_URL = os.environ["HEARTBEAT_URL"]

def sync_data():
    # Ihre Logik
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # Heartbeat wird nicht gesendet - Monitoring alarmiert Sie
    raise

Node.js: async / await

const HEARTBEAT_URL = process.env.HEARTBEAT_URL;

async function nightlyJob() {
  await processInvoices();
  await fetch(HEARTBEAT_URL, { signal: AbortSignal.timeout(10000) });
}

nightlyJob().catch(err => {
  console.error(err);
  process.exit(1);
});

Grace Period: wie viel Zeit vor dem Alert geben

Heartbeat-Monitor braucht Toleranz - der Cron läuft manchmal länger als üblich, das Netzwerk hat Latenz, NTP-Sync kann leicht verschoben sein. Die Grace Period ist die Zeit nach dem erwarteten Intervall, in der das Monitoring noch wartet.

Praktische Werte:

  • Hourly Cron: Intervall 60 Min + Grace 10 Min
  • Daily Backup (durchschnittlich 20 Min): Intervall 1440 Min + Grace 60 Min
  • Weekly Report: Intervall 10080 Min + Grace 360 Min (6 Std)

Zu enge Grace = False-Positive-Alerts. Zu locker = verzögerte Warnung, wenn es wirklich fällt.

Wo das Heartbeat-Pattern am meisten hilft

  • Nächtliche DB-Backups
  • Sync mit externen APIs (CRM, Accounting, Payment)
  • Berichtskalkulationen
  • Cleanup-Tasks (Löschen alter Sessions, Logs, temporärer Dateien)
  • Healthcheck-Zyklus langlaufender Worker
  • Geplante E-Mails, Newsletter, Rechnungserstellung

Fazit

Background-Tasks sind oft kritischer als die Website selbst, bleiben aber ein blinder Fleck des Monitorings. Das Heartbeat-Pattern erfordert 5 Minuten Implementierung (Hinzufügen von curl ans Ende der Cron-Zeile) und bietet die gleiche Ruhe wie Uptime-Monitoring fürs Frontend.

Beginnen Sie Cron-Jobs zu überwachen

ePulz.io unterstützt Heartbeat-Checks mit konfigurierbarer Grace Period. 7 Tage kostenlos.

Monitoring starten →


ePulz.io kostenlos testen - 7 Tage, ohne Kreditkarte.

Konto erstellen