Cron-Monitoring
für stille Fehler.

Cron-Job-Monitoring prüft, ob geplante Aufgaben tatsächlich laufen. Jeder Job pingt nach Abschluss eine eigene URL, und der Monitoring-Dienst alarmiert Sie, wenn ein Ping nicht rechtzeitig eintrifft. So fällt auf, was Logs nicht zeigen: Ein Job, der nie gestartet ist, schreibt überhaupt keinen Fehler. Bei Hyperping heißen diese Monitore Healthchecks.

Legen Sie einen Healthcheck mit dem Zeitplan des Jobs an, als Intervall oder als Cron-Ausdruck mit Zeitzone, und geben Sie eine Karenzzeit an. Kopieren Sie die Ping-URL und hängen Sie ans Ende des Jobs einen Request an, in Ihrer Crontab etwa && curl -fsS gefolgt von der URL. Kommt der Ping nicht bis zur erwarteten Zeit plus Karenzzeit an, alarmiert Sie Hyperping.

Dieselbe Idee unter anderen Namen. Statt dass ein Monitor Ihren Dienst prüft, sendet Ihr Job bei jedem Lauf ein Signal, den Heartbeat, und der Alarm geht los, wenn das Signal ausbleibt. Das passt zu allem, was keine URL zum Prüfen hat: Cron-Jobs, Backups, Queue-Worker, ETL-Pipelines und geplante CI-Workflows.

Pingen Sie nur, wenn der Job erfolgreich war: In einer Shell hängen Sie den Request mit && an den Befehl, im Code rufen Sie die URL auf, nachdem die Arbeit erledigt ist. Ein Job, der abstürzt, mit einem Fehler endet oder nie startet, sendet dann nichts, und Hyperping alarmiert Sie nach Ablauf der Karenzzeit. Hyperping speichert weder Exit-Code noch Ausgabe des Jobs, die Ursache finden Sie also weiterhin in Ihren Logs.

Die Zeit, die Hyperping nach der erwarteten Ausführungszeit wartet, bevor alarmiert wird. Ein Backup, das für 2:00 Uhr geplant ist und 30 Minuten Karenzzeit hat, kann bis 2:30 Uhr pingen. Setzen Sie sie etwas über die übliche Dauer des Jobs, damit langsame Läufe niemanden wecken. Sie beginnt bei 1 Minute und steht im Dashboard standardmäßig auf 10 Minuten.

Ja. Geben Sie einem Healthcheck im Cron-Modus den fünfteiligen Ausdruck des Jobs, etwa 0 9 * * 1-5, und seine Zeitzone, etwa America/New_York. Hyperping berechnet daraus jeden erwarteten Lauf, sodass Wochenenden ohne Läufe keinen Alarm auslösen und Zeitumstellungen berücksichtigt werden. Einen Ausdruck erstellen oder prüfen Sie mit dem Generator für Cron-Ausdrücke.

Ja. Pingen Sie zu Beginn des Jobs die URL mit angehängtem /start und am Ende die normale URL. Der Verlauf des Healthchecks zeigt die Dauer jedes Laufs, dazu Zeit, IP-Adresse, Methode und User-Agent jedes Pings. Ein Lauf, der startet, aber nie endet, verpasst seine Frist und alarmiert wie ein ausgebliebener Lauf.

Ja. Alles, was einen HTTP-Request senden kann, kann einen Healthcheck pingen: curl oder wget in einer Crontab, ein systemd-Timer oder ein Kubernetes-CronJob, ein Schritt am Ende eines Workflows in GitHub Actions oder GitLab CI, Invoke-WebRequest in einer geplanten Windows-Aufgabe oder ein Request aus Ihrem Code in einem Laravel-, Rails-, Django- oder Node.js-Scheduler.

Uptime-Monitoring prüft einen Dienst von außen: Hyperping ruft Ihre Website oder API ab, auf Wunsch alle 30 Sekunden, und alarmiert, wenn sie nicht mehr antwortet. Cron-Job-Monitoring funktioniert andersherum: Ihr Job ruft Hyperping auf, und Stille ist der Fehler. Die meisten Teams brauchen beides, und Hyperping betreibt beides nebeneinander. Siehe Uptime-Monitoring.

Healthchecks sind in jedem Plan enthalten, auch im Free-Plan. Jeder Healthcheck zählt als einer der Monitore des Plans: 20 bei Free, 50 bei Essentials, 250 bei Pro und 1.000 bei Business, gemeinsam mit Ihren Uptime-Checks. Siehe Preise.

Cronitor geht bei der Job-Analyse tiefer, und Healthchecks.io ist Open Source und lässt sich kostenlos selbst hosten. Hyperping hält das Cron-Monitoring neben Uptime-Checks, Statusseiten und Incidents in einem Konto. Den direkten Vergleich finden Sie unter die besten Tools für Cron-Job-Monitoring.