Heartbeat-Monitoring

Ihre Cronjobs schlagen fehl.
Still.

Ein Heartbeat-Check ist ein Totmannschalter für Ihre geplanten Jobs. Ihr Job pingt eine URL, wenn er fertig ist. Wenn der Ping nicht ankommt — Prozess abgestürzt, Server neugestartet, Job hängt — weckt SteadyCron Sie auf.

Kostenlos starten Dokumentation lesen

Kostenloser Tarif — keine Kreditkarte erforderlich.

Ohne Heartbeat-Check

# /etc/cron.d/backup
0 2 * * * root /usr/bin/backup.sh

# Output: none.
# Exit code: who knows.
# Last successful run: unclear.
# Will anyone notice? No.

Mit Heartbeat-Check

# /etc/cron.d/backup
0 2 * * * root /usr/bin/backup.sh \
  && curl -fsS https://ping.steadycron.com/abc123

✓ 02:04 — Ping empfangen, Job gesund
✗ 03:02 — kein Ping — Alarmierung #ops-slack

Das Problem

Fire-and-forget ist keine Überwachungsstrategie

Cron hat kein eingebautes Konzept von Erfolg oder Misserfolg. Ein Job läuft, erzeugt Ausgabe, die niemand liest, und endet — und der Scheduler betrachtet seinen Auftrag als erledigt. Bis Sie merken, dass etwas schiefgelaufen ist, sind die Logs rotiert, das Zeitfenster ist geschlossen und der Schaden ist angerichtet.

Das nächtliche Backup ist still fehlgeschlagen. Die Daten sind weg.
Der Invoice-Job läuft seit drei Tagen nicht. Finance hat es zuerst bemerkt.
Ein Skript hat gehangen und den nächsten Lauf blockiert — für sechs Stunden.
Der Prozess wurde durch OOM beendet. Logs bereits rotiert.

Eine typische Cron-Fehler-Timeline

02:00

Job zur Ausführung geplant

02:00

Prozess gestartet

02:03

Datenträger voll — Exit-Code 1

02:03

Ausgabe: keine (umgeleitet)

03:00

Log-Rotation läuft

09:14

Entwickler öffnet Dashboard

09:14

Keine sichtbaren Fehler

14:30

Kunde meldet Datenverlust

12 Stunden zwischen Ausfall und Entdeckung.

So funktioniert es

Stille ist das Signal

Sie senden keine Daten an uns — das macht Ihr Job. Wenn er aufhört, wissen wir es.

01

Ihr Job pingt eine URL

Nachdem Ihr Skript läuft, ruft es eine eindeutige Ping-URL auf — nichts weiter als ein einzelner HTTP-GET. Übergeben Sie /start vorher, /success danach und optional /fail bei einem Fehler.

curl -fsS https://ping.steadycron.com/{id}

02

Wir öffnen ein Toleranzfenster

SteadyCron kennt Ihren Zeitplan und erlaubt eine konfigurierbare Toleranzzeit, um normales Jitter zu absorbieren — Wartungsfenster um Mitternacht, Server-Last-Spitzen und Zeitplanabweichungen.

grace: 10m # no alert if ping arrives within 10 min

03

Stille löst einen Alarm aus

Wenn der Ping nicht vor Ablauf der Toleranzzeit eintrifft, wird ein Alarm an Ihren konfigurierten Kanal gesendet — Slack, E-Mail, Telegram, Discord oder Webhook.

→ #ops-slack nightly-backup missed (14 h overdue)

Was wir erkennen

Drei Wege, wie ein Job schiefgehen kann

Jeder Fehlertyp ist eindeutig, erkennbar und löst Alarme unabhängig aus.

nightly-backup MISSED

Verpasster Lauf

Der Job hat nie gestartet. Der Prozess wurde beendet, der Server neugestartet oder der Scheduler hat ihn übersprungen. Kein Ping kam an — nicht einmal ein /fail.

Erwartet um 02:00 UTC

Letzter Ping gestern 02:04

Überfällig seit 14 Std. 22 Min.

Erkannt, wenn: kein /start- oder /success-Ping innerhalb des Toleranzfensters des erwarteten Zeitplans eintrifft.

invoice-sender FAILED

Job fehlgeschlagen

Der Job lief, aber endete mit einem Fehler-Exit-Code, oder Ihr Code fing eine Ausnahme ab und rief explizit den /fail-Endpunkt auf, bevor er zurückkehrte.

...
$ python invoice.py
ConnectionError: DB unreachable
→ /fail ping sent
Alerted: #billing-alerts

Erkannt, wenn: Ihr Code den /fail-Endpunkt aufruft oder der Job ohne /success-Ping endet.

report-generator TIMED OUT

Hängender Job

Der Job startete — /start wurde empfangen — hat aber nie /success gesendet. Er läuft noch, oder er ist still in einem Deadlock. Ein Maximalzeit-Schwellenwert erkennt ihn.

/start empfangen 09:00:12

Maximale Dauer 30 min

/success empfangen nie

Erkannt, wenn: ein /start empfangen wurde, aber /success oder /fail nie innerhalb der konfigurierten maximalen Dauer eintrifft.

Integration

Eine Zeile. Jede Sprache.

Kein SDK zu installieren, kein Agent zu deployen. Ein HTTP-GET ist die Integration. Funktioniert aus einem Shell-Skript, einem Python-Lambda, einem Go-Binary oder einem Kubernetes-CronJob.

# Minimal — one line at the end of your crontab command
0 2 * * * /usr/bin/backup.sh && curl -fsS https://ping.steadycron.com/abc123

# With start/fail signals (recommended)
0 2 * * * curl -fsS https://ping.steadycron.com/abc123/start \
  && /usr/bin/backup.sh \
  && curl -fsS https://ping.steadycron.com/abc123 \
  || curl -fsS https://ping.steadycron.com/abc123/fail

import requests, subprocess, sys

PING = "https://ping.steadycron.com/abc123"

requests.get(f"{PING}/start", timeout=5)
result = subprocess.run(["/usr/bin/backup.sh"])

if result.returncode == 0:
    requests.get(PING, timeout=5)
else:
    requests.get(f"{PING}/fail", timeout=5)
    sys.exit(result.returncode)

const PING = "https://ping.steadycron.com/abc123";

await fetch(`${PING}/start`);
try {
  await runMyJob();
  await fetch(PING);             // success
} catch (err) {
  await fetch(`${PING}/fail`);   // explicit failure
  throw err;
}

const ping = "https://ping.steadycron.com/abc123"

http.Get(ping + "/start")

if err := runMyJob(); err != nil {
    http.Get(ping + "/fail")
    log.Fatal(err)
}

http.Get(ping) // success

require "net/http"
PING = "https://ping.steadycron.com/abc123"

Net::HTTP.get(URI("#{PING}/start"))
begin
  run_my_job
  Net::HTTP.get(URI(PING))          # success
rescue => e
  Net::HTTP.get(URI("#{PING}/fail"))
  raise
end

https://ping.steadycron.com/abc123";

file_get_contents(PING . "/start");
try {
    run_my_job();
    file_get_contents(PING);          // success
} catch (\Throwable $e) {
    file_get_contents(PING . "/fail");
    throw $e;
}

Die Ping-URL wird beim Erstellen des Checks generiert — kopieren Sie sie in Ihr Skript. Monitore lieber als Code definieren? Deklarieren Sie sie in YAML oder Terraform.

Intelligente Alarme · Toleranzzeiten

Nicht jede Verzögerung ist ein Fehler

Zeitpläne sind Richtwerte. Serverlast, Wartungsfenster um Mitternacht und Schaltsekunden verschieben Jobs ein paar Minuten über ihre geplante Zeit hinaus. Eine Toleranzzeit absorbiert dieses normale Jitter, sodass Sie nur alarmiert werden, wenn etwas wirklich nicht stimmt.

Setzen Sie es pro Check — ein schneller 5-Minuten-Health-Ping kann eine 2-Minuten-Toleranz verwenden; ein schwerer nächtlicher ETL, der manchmal 20 Minuten dauert, kann 30 verwenden.

Toleranzzeit in Aktion

02:00

Erwarteter Ping

02:06

Ping eingetroffen (6 Min. verspätet)

innerhalb der 10-Min.-Toleranz — kein Alarm

03:00

Erwarteter Ping

03:11

Kein Ping (11 Min. verspätet)

Toleranzzeit abgelaufen — Alarmierung

grace: 600 # seconds — 10 minutes

Intelligente Alarme · Rauschreduzierung

Entwickelt, um Rauschen zu reduzieren, nicht hinzuzufügen

Alarmmüdigkeit ist real. SteadyCron hat mehrere Mechanismen, um Ihren Pager ruhig zu halten, es sei denn, etwas braucht wirklich Ihre Aufmerksamkeit.

Schwellenwert für aufeinanderfolgende Fehlschläge

Ein einzelnes Flackern — ein kurzer Netzwerkausfall, ein einmaliger OOM-Kill — sollte Ihr Team nicht um 3 Uhr morgens alarmieren. Legen Sie einen Schwellenwert von N aufeinanderfolgenden Fehlschlägen fest, bevor ein Alarm ausgelöst wird. Der erste Fehlschlag wird protokolliert; der dritte löst den Alarm aus.


alert_after: 3 # Alarm erst nach 3 aufeinanderfolgenden Fehlschlägen

Flapping-Schutz

Ein Job, der schnell zwischen gesund und fehlerhaft wechselt, erzeugt einen Sturm von Alarmen ohne nützliches Signal. Der Flapping-Schutz erkennt diese Oszillation und unterdrückt Wiederholungsbenachrichtigungen, bis der Job sich stabilisiert — ein Alarm, nicht zwanzig.

 # fail → ok → fail → ok → fail
 ⚠ Flapping erkannt — Alarm zurückgehalten

Ruhezeiten

Markieren Sie ein Zeitfenster pro Check, in dem nicht kritische Fehlschläge unterdrückt werden — der Alarm wird protokolliert, aber nicht zugestellt. Wenn Ihr Team wieder online ist, ist alles, was passiert ist, im Zustellungsprotokoll mit dem Unterdrückungsgrund.


quiet_hours: "22:00–07:00 Europe/Berlin"

Alarm-Lebenszyklus

🔴

nightly-backup verpasst

02:14 — Alarm an #ops-slack gesendet

📋

Alarm unterdrückt (Ruhezeit)

03:00 — folgender Fehlschlag protokolliert, nicht gesendet

✅

nightly-backup wiederhergestellt

02:07 nächsten Tag — automatisch aufgelöst

🔕

#ops-slack benachrichtigt: aufgelöst

Keine manuelle Bestätigung erforderlich

Intelligente Alarme · Automatische Auflösung

Alarme lösen sich selbst auf

Wenn sich ein Job erholt — der nächste Ping erfolgreich eintrifft — löst SteadyCron den offenen Alarm automatisch auf und sendet eine Auflösungsbenachrichtigung an denselben Kanal. Sie müssen ein Vorkommnis, das sich bereits selbst behoben hat, nie manuell schließen.

Jedes Alarmereignis wird mit seinem Auslöser, Zustellungskanal, Status und ggf. Unterdrückungsgrund protokolliert — so haben Sie immer eine vollständige Aufzeichnung darüber, was ausgelöst wurde, was zurückgehalten wurde und warum.

Eine Plattform, drei Aufgaben

HTTP-Ausführung

Endpunkte planmäßig aufrufen — Wiederholungen, Timeouts und vollständige Laufprotokolle.

Heartbeat-Monitoring

Sie sind hier

Überwachen Sie Jobs, die Sie überall betreiben — Alarm, sobald einer verstummt.

Cron as Code

Jeden Job, Monitor und Alert in YAML oder Terraform definieren.

Ihre Jobs sollten Ihnen mitteilen, dass sie gelaufen sind.

Fügen Sie in zwei Minuten einen Heartbeat-Check hinzu. Kein Agent, kein SDK, keine Infrastrukturänderung — nur eine URL am Ende Ihres Skripts.

Kostenlos starten Dokumentation lesen

Kostenloser Tarif — keine Kreditkarte
EU-gehostet, DSGVO-konform
Jede Sprache, jede Plattform