Cronjob-Monitoring
für verpasste Läufe.
Heartbeat-Monitoring für Backups, Berichte und jede geplante Aufgabe. Jeder Job ruft am Ende seine eigene URL auf, und Ihr Team wird alarmiert, wenn ein Lauf ausbleibt.
In jedem Plan enthalten, auch in Free. Keine Kreditkarte erforderlich.
Teams vertrauen auf Hyperping, wenn Uptime an erster Stelle steht.
Erfolgsgeschichten lesen
Sechs Arten, wie ein Cron-Job still ausfällt. Bei jeder bleibt der Ping aus.
Cron-Job-Monitoring macht aus Stille einen Alarm. Jeder Job pingt Hyperping, wenn er läuft, und ein Ping, der nicht rechtzeitig eintrifft, gilt als Ausfall. So fällt auf, was Logs nicht zeigen: Ein Job, der nie gestartet ist, schreibt überhaupt keinen Fehler.
- 0 2 * * * · rebooted at 01:58no ping by 02:30 · alert
Der Job, der nie gestartet ist
Ein Neustart, ein Container, der nicht wieder hochkam, eine Crontab, die bei einem Redeploy verloren ging. Nichts läuft, also wird auch kein Fehler geloggt. Der fehlende Ping ist die einzige Spur, und sie reicht.
So funktionieren Healthchecks - backup.sh · exit 1&& curl skipped · alert
Der Job, der abgestürzt ist
Hängen Sie den Ping mit && an den Befehl, dann pingt ein Lauf, der mit einem Fehler endet, nie. Hyperping alarmiert Sie, sobald die Karenzzeit abgelaufen ist.
Nur bei Erfolg pingen - /start 02:00 · no end pingdeadline passed · alert
Der Job, der hängt
Ein Lock, der nie freigegeben wird, eine Abfrage, die an einer Tabelle festhängt. Pingen Sie /start, wenn der Job beginnt, und die URL, wenn er endet: Die Dauer jedes Laufs wird protokolliert, und ein Lauf, der nie endet, verpasst seine Frist.
Laufzeit messen - 0 2 * * * · read as UTCcron mode · Europe/Paris
Der Zeitplan in der falschen Zeitzone
Geben Sie dem Healthcheck den Cron-Ausdruck und die Zeitzone des Jobs. Die Frist folgt damit auch der Sommerzeit: Ein Job, der um 2:00 Uhr Pariser Zeit läuft, wird um 2:00 Uhr Pariser Zeit erwartet.
Generator für Cron-Ausdrücke - worker · last ping 47 min agoevery 15 min · alert
Der Worker, der still aufgehört hat
Ein Queue-Consumer, eine Sync-Schleife, ein Laravel- oder Rails-Scheduler. Alles, was in einer Schleife läuft, kann bei jedem Durchlauf pingen, und der einfache Modus alarmiert, wenn die Pings ausbleiben.
Einfacher Modus - GitHub Actions · schedule offno ping · alert
Der geplante Workflow, der unbemerkt abgeschaltet wurde
GitHub deaktiviert geplante Workflows in öffentlichen Repositories nach 60 Tagen ohne Aktivität, und ein CI-Runner kann in der Warteschlange hängen bleiben. Ein Ping als letzter Schritt des Workflows zeigt Ihnen, wann er nicht mehr gelaufen ist.
Beispiel für GitHub Actions
Eine URL pro Job. Eine Zeile in Ihrer Crontab.
Kein Agent, kein SDK. Ein Healthcheck ist eine URL, die Ihr Job aufruft, und Hyperping behält die Uhr im Blick.
- 1
Healthcheck anlegen
Benennen Sie ihn nach dem Job und geben Sie ihm dessen Zeitplan: ein Intervall oder denselben Cron-Ausdruck mit Zeitzone. Legen Sie eine Karenzzeit fest, die etwas länger ist als ein normaler Lauf.
- 2
Seine URL pingen, wenn der Job fertig ist
Ein HEAD-, GET- oder POST-Request von allem, was HTTP spricht. In einer Crontab verketten Sie ihn mit
&&, damit nur ein erfolgreicher Lauf pingt. Pingen Sie zu Beginn zusätzlich/start, um die Dauer jedes Laufs zu erfassen. - 3
Alarm, wenn ein Lauf ausbleibt
Kein Ping bis zur erwarteten Zeit plus Karenzzeit, und der Healthcheck gilt als ausgefallen: Ein Incident wird eröffnet, und Ihre Kanäle werden innerhalb von Sekunden alarmiert. Der nächste Ping schließt ihn und sendet eine Entwarnung.
# Back up at 2:00 every night, ping Hyperping only if it succeeds
0 2 * * * /usr/local/bin/backup.sh && curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4#!/bin/sh
set -e
# The run starts: its duration is measured from here
curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4/start
pg_dump "$DATABASE_URL" | gzip > /backups/db-$(date +%F).sql.gz
# The run ends: Hyperping logs the duration and the next deadline
curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4await sendInvoices();
// Ping at the end of the job
await fetch("https://hc.hyperping.io/tok_8f3kq2Lm9xV4");import requests
build_report()
# Ping at the end of the job
requests.get("https://hc.hyperping.io/tok_8f3kq2Lm9xV4", timeout=10)use Illuminate\Support\Facades\Schedule;
// Laravel pings /start before the run, and the URL only if it succeeds
Schedule::command("backup:run")
->dailyAt("02:00")
->timezone("Europe/Paris")
->pingBefore("https://hc.hyperping.io/tok_8f3kq2Lm9xV4/start")
->pingOnSuccess("https://hc.hyperping.io/tok_8f3kq2Lm9xV4");func main() {
if err := syncInventory(); err != nil {
// No ping: Hyperping alerts once the grace period runs out
log.Fatal(err)
}
// Ping at the end of the job
client := http.Client{Timeout: 10 * time.Second}
if _, err := client.Get("https://hc.hyperping.io/tok_8f3kq2Lm9xV4"); err != nil {
log.Printf("ping failed: %v", err)
}
}on:
schedule:
- cron: "0 2 * * *"
jobs:
backup:
runs-on: ubuntu-latest
steps:
- run: ./backup.sh
- run: curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-report
spec:
schedule: "0 6 * * *"
timeZone: "Europe/Paris"
jobTemplate:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: report
image: ghcr.io/acme/report:latest
command: ["/bin/sh", "-c"]
args: ["./report.sh && curl -fsS https://hc.hyperping.io/tok_8f3kq2Lm9xV4"]# Started every night by backup.timer (OnCalendar=*-*-* 02:00:00)
[Unit]
Description=Nightly database backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
# Runs only if ExecStart exited with success
ExecStartPost=/usr/bin/curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4# Run the job's container, ping only if it exits with code 0
0 2 * * * docker run --rm --env-file /etc/backup.env ghcr.io/acme/backup:latest && curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4
# Same with a Compose service
0 3 * * * cd /srv/app && docker compose run --rm report && curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4# Windows Task Scheduler action: powershell.exe -File C:\jobs\export-orders.ps1
& C:\jobs\export-orders.exe
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
# Ping at the end of the job
Invoke-RestMethod -Uri "https://hc.hyperping.io/tok_8f3kq2Lm9xV4" -TimeoutSec 10Einfach oder Cron. In der Zeitzone des Jobs.
Ein Healthcheck weiß, wann der nächste Lauf fällig ist. Deshalb alarmiert er beim Lauf, der nicht stattgefunden hat, und nicht erst Stunden später, wenn es jemandem auffällt.
- 1
Einfacher Modus, für Schleifen und Worker
Erwarten Sie alle paar Minuten, Stunden oder Tage einen Ping, ab einer Minute. Die Uhr beginnt bei jedem Ping neu, das passt zu Workern und Syncs, die in einer Schleife laufen.
- 2
Cron-Modus, für geplante Jobs
Fügen Sie den fünfteiligen Ausdruck des Jobs ein und wählen Sie seine Zeitzone. Jeder Lauf wird dann erwartet, wenn Cron ihn starten würde, Wochenenden und Zeitumstellungen inklusive. Unsicher bei der Syntax? Nutzen Sie den Generator für Cron-Ausdrücke.
- 3
Eine Karenzzeit für langsame Läufe
Wie lange nach der erwarteten Zeit gewartet wird, bevor ein Alarm rausgeht: 10 Minuten, sofern Sie nichts ändern. Ein Backup, das meist 4 Minuten dauert, kann 30 bekommen, damit eine langsame Nacht niemanden weckt.
- Mode
- Simple
- Every
- 15 minutes
- Grace period
- 5 minutes
- Last ping
- Oct 6, 09:14:58
- Down if no ping by
- Oct 6, 09:34:58
- Oct 6, 09:29:58 · next ping expected
- Oct 6, 09:34:58 · end of grace period
Im einfachen Modus beginnt die Uhr bei jedem Ping neu: 15 Minuten bis zum nächsten, plus 5 Minuten Karenzzeit. Ein Worker, der nicht mehr pingt, wird 20 Minuten nach seinem letzten Durchlauf gemeldet.
- Mode
- Cron
- Expression
- 0 2 * * *
- Timezone
- Europe/Paris
- Grace period
- 30 minutes
- Down if no ping by
- Oct 7, 02:30 CEST
- Wed, Oct 7 · 02:00 CEST
- Thu, Oct 8 · 02:00 CEST
- Fri, Oct 9 · 02:00 CEST
Im Cron-Modus folgt die Frist dem Ausdruck, nicht dem letzten Ping. Ein Backup, das heute Nacht um 02:04 pingt, wird morgen trotzdem um 02:00 erwartet, mit 30 Minuten Karenzzeit.
- Mode
- Cron
- Expression
- 0 9 * * 1-5
- Timezone
- America/New_York
- Grace period
- 15 minutes
- Down if no ping by
- Nov 2, 09:15 EST
- Mon, Nov 2 · 09:00 EST
- Tue, Nov 3 · 09:00 EST
- Wed, Nov 4 · 09:00 EST
Der Bericht vom Freitag hat um 09:02 gepingt. Am Wochenende wird nichts erwartet, also gibt es auch keinen Alarm, und die Zeitumstellung am 1. November verschiebt den Lauf am Montag nicht: Die Zeitzone rechnet mit.
- Mode
- Cron
- Expression
- 0 0 1 * *
- Timezone
- UTC
- Grace period
- 2 hours
- Down if no ping by
- Nov 1, 02:00 UTC
- Sun, Nov 1 · 00:00 UTC
- Tue, Dec 1 · 00:00 UTC
- Fri, Jan 1 · 00:00 UTC
Bei einem monatlichen Job fällt ein Ausfall oft wochenlang niemandem auf. Eine Karenzzeit von zwei Stunden lässt Raum für einen langsamen Lauf und schlägt trotzdem Alarm, lange bevor jemand fragt, wo die Rechnungen bleiben.
Ein verpasster Lauf ist ein Incident. Ihr Team erfährt es zuerst.
Healthchecks werden alle paar Sekunden mit ihrer Frist abgeglichen. Der Alarm geht also raus, sobald die Karenzzeit endet, und der Incident steht in derselben Liste wie Ihre anderen Monitore.
- Onlinepinged on schedule
Der letzte Lauf hat rechtzeitig gepingt. Die nächste Frist ergibt sich aus dem Zeitplan: der nächste Ping im einfachen Modus, der nächste Cron-Lauf im Cron-Modus.
- Kulanzzeitdue, no ping yet
Der Lauf ist fällig und hat sich noch nicht gemeldet. Der Healthcheck bleibt online und nichts wird gesendet, bis die Kulanzzeit abläuft, damit ein Job, der ein paar Minuten länger dauert, still bleibt.
- Ausgefallenmissed its scheduled ping
Die Karenzzeit ist abgelaufen. Ein Incident wird eröffnet, alle Kanäle werden gleichzeitig alarmiert, und der Healthcheck bleibt ausgefallen, bis der Job wieder pingt: ein Alarm pro verpasstem Lauf, nicht einer pro Minute.
- Wiederhergestelltback on schedule
Der nächste Ping schließt den Incident und sendet eine Entwarnung über dieselben Kanäle. Alarme in PagerDuty und Opsgenie schließen sich von selbst.
Wo Ihr Team arbeitet.Überall gleichzeitig, sobald ein Lauf ausbleibt.
E-Mail und SMS erreichen jedes Mitglied des Projekts, Slack, Discord und Telegram die verbundenen Kanäle. Leiten Sie den Alarm an PagerDuty oder Opsgenie weiter, um dort die Person in Rufbereitschaft zu alarmieren.
Slack
PagerDuty
Opsgenie
Discord
Telegram- SMS
Neben Ihren Uptime-Checks. Auf derselben Statusseite.
Healthchecks liegen im selben Konto wie Ihre Monitore, Incidents und Statusseiten. Ein verpasster Import und eine langsame API landen also im selben Dashboard.
- Oct 06 02:48:21 · OK · 4m 09slast 20 pings kept
Jeder Lauf, protokolliert
Jeder Ping speichert Zeit, IP-Adresse, Methode und User-Agent, dazu die Dauer des Laufs, wenn er mit /start begonnen hat. Ein 24-Stunden-Diagramm zeigt die Läufe Stunde für Stunde.
Ping-Verlauf - Nightly database backup · 99.93%uptime bars · status page
Auf Ihrer Statusseite
Fügen Sie einen Healthcheck neben Ihren Websites und APIs zu einer Statusseite hinzu. Kunden sehen den Import, den Sync oder den Bericht als weiteren Dienst, online oder ausgefallen, mit seiner Uptime.
Statusseiten - 30 days · uptime · CSVweekly report email
In Ihren Berichten
Die Uptime eines Healthchecks wird aus seinen Ausfällen berechnet, standardmäßig über 30 Tage, lässt sich als CSV exportieren und steht neben Ihren Monitoren im Wochenbericht.
Reporting
Healthchecks als Code. Über die API, Terraform oder Ihren KI-Agenten.
- 1
Über die API anlegen
Senden Sie per POST name, einen cron-Ausdruck und seine timezone oder period_value und period_type, dazu die Karenzzeit. Die Antwort enthält die Ping-URL, die Sie Ihrem Job übergeben.
- 2
Oder in Terraform deklarieren
Die Ressource hyperping_healthcheck hält den Healthcheck jedes Jobs neben der Infrastruktur, die ihn ausführt, und gibt seine Ping-URL als sensiblen Wert aus.
- 3
Fragen Sie Ihren KI-Agenten, ob das Backup gelaufen ist
Der MCP-Server listet Ihre Healthchecks mit Status, letztem Ping und nächster Frist auf, so kann Claude, Cursor oder ein anderer Agent die Frage „Sind die Jobs heute Nacht gelaufen?“ beantworten.
curl -X POST https://api.hyperping.io/v2/healthchecks \
-H "Authorization: Bearer $API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Nightly database backup",
"cron": "0 2 * * *",
"timezone": "Europe/Paris",
"grace_period_value": 30,
"grace_period_type": "minutes"
}'resource "hyperping_healthcheck" "nightly_backup" {
name = "Nightly database backup"
cron = "0 2 * * *"
timezone = "Europe/Paris"
grace_period_value = 30
grace_period_type = "minutes"
}
output "backup_ping_url" {
value = hyperping_healthcheck.nightly_backup.ping_url
sensitive = true
}{
"uuid": "hc_Kq3vX9mPzL2wR8tY5nB7cD4f",
"name": "Nightly database backup",
"state": "up",
"last_ping_at": "2026-10-06T00:04:12.000Z",
"next_ping_due_at": "2026-10-07T00:00:00.000Z",
"down_if_no_ping_by": "2026-10-07T00:30:00.000Z",
"schedule": "cron '0 2 * * *' (Europe/Paris)",
"grace": "30 minutes"
}Ein Leitfaden für Ihren Scheduler. Wohin der Ping gehört und wie er scheitert.
Jeder Scheduler verbirgt Fehler auf seine Weise. Jeder Leitfaden ist ein getestetes Setup: was schiefgeht, wie Sie es mit den eigenen Tools des Schedulers sehen, und der Healthcheck, der den verpassten Lauf erkennt. Leitfäden auf Englisch.
Server und Plattformen
- systemd-TimerPersistent=true, Zeitzonen, ein Ping nur bei Erfolg.
- Windows-AufgabenplanungEine fehlgeschlagene Aufgabe, die Erfolg meldet.
- Kubernetes-CronJobsVerpasste Zeitpläne und Pods, die in Pending hängen.
- Geplante GitHub-Actions-WorkflowsVerspätete Läufe und die automatische Deaktivierung nach 60 Tagen.
- Vercel-Cron-JobsKeine Wiederholungen, Weiterleitungen und Timeouts.
- Cloudflare-Workers-Cron-TriggerswaitUntil, und 1 bedeutet Sonntag.
Frameworks und Queues
- Laravel-SchedulerpingOnSuccess oder thenPing, und schedule:run.
- Geplante Rails-JobsSolid Queue, GoodJob und whenever.
- Node.js-Cron-Jobsnode-cron, BullMQ und Agenda.
- Celery beatEin Beat, der ohne Worker veröffentlicht.
- Sidekiq-Cron-JobsWiederholungen, die den Fehler verbergen.
- pg_cronJobs, die nach einem Neustart oder Failover stoppen.
Jobs, die nicht still scheitern dürfen
Vergleichen
- Hyperping vs. CronitorEin Tarif statt eines Preises pro Monitor und pro Nutzer.
- Hyperping vs. Healthchecks.ioDieselben Ping-URLs, neben Uptime-Monitoring und Statusseiten.
- Hyperping vs. Sentry CronsKeine Gebühr pro Cron-Monitor zusätzlich zum Tarif.
- Hyperping vs. Dead Man’s SnitchCron-Ausdrücke in der Zeitzone jedes Jobs.
Ein Dienst, der immer antworten soll? Das ist Uptime-Monitoring.
Healthchecks warten darauf, dass Ihre Jobs sich melden. Uptime-Monitore rufen Ihre Websites und APIs selbst auf, auf Wunsch alle 30 Sekunden und aus bis zu 17 Regionen. Die meisten Teams nutzen beides, im selben Plan.
Was 50 oder 500 Jobs kosten. Kostenlose Pläne inklusive.
Wenn Sie nur Cron-Jobs überwachen, ist Healthchecks.io günstiger. Hyperping lohnt sich, wenn derselbe Plan auch Ihre Websites und APIs überwacht und Ihre Statusseite betreibt: Healthchecks zählen zu den Monitoren des Plans, pro Job wird nichts berechnet, und Essentials enthält 3 Nutzerplätze.
| MonatspreisUSD, monatliche Abrechnung, ein Nutzer | HyperpingHealthchecks zählen als Monitore | Healthchecks.ioCron-Monitoring, Open Source | CronitorAbrechnung pro Monitor und pro Nutzer |
|---|---|---|---|
| Kostenloser Plan | 20 JobsGeteilt mit den Uptime-Monitoren | 20 JobsHobbyist | 5 JobsHacker, 1 Nutzer |
| 50 Jobs | $29Essentials, 24 $ bei jährlicher Zahlung | $20Business, bis zu 100 Jobs | $10550 × 2 $, plus 5 $ pro Nutzer |
| 500 Jobs | $299Business, 249 $ bei jährlicher Zahlung | $80Business Plus, bis zu 1.000 Jobs | $1,005500 × 2 $, plus 5 $ pro Nutzer |
| Ebenfalls im Preis | Uptime-Monitore, Statusseiten, Bereitschaft für MonitoreIm selben Monitor-Kontingent | Nur Cron-MonitoringOpen Source, kostenlos selbst zu hosten | Uptime-Checks, StatusseiteEbenfalls pro Monitor berechnet |
Preise am 8. Oktober 2026 auf der Preisseite jedes Anbieters geprüft. Alle Tools und ihre Grenzen im Vergleich: die besten Cron-Job-Monitoring-Tools (auf Englisch).
Das sagen Teams über Hyperping.
@hyperping ist wirklich großartig
Hyperping hat bei uns im Unternehmen den Ruf, reaktionsschneller zu sein als Datadog. Benachrichtigungen von Hyperping erhalten wir meist vor denen von Datadog.
Wir haben uns für Hyperping entschieden, um unseren Nutzern ein hochwertiges Dashboard für Incidents und Statusmeldungen zu bieten.
Die Echtzeit-Alarme von Hyperping sagen uns, wenn die App ausfällt. Manchmal kommen sie sogar, bevor AWS es bemerkt oder uns benachrichtigt.
Wir können uns nicht mehr vorstellen, unser SaaS-Geschäft ohne Hyperping zu betreiben.
Hyperping überzeugt auf ganzer Linie: von der reibungslosen Einrichtung über die Gewissheit, dass alles läuft, bis zum aufmerksamen Kundenservice.
Fragen zum Cron-Job-Monitoring.
Was ist Cron-Job-Monitoring?
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.
Wie überwache ich einen Cron-Job?
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.
Was ist Heartbeat-Monitoring oder ein Totmannschalter (Dead Man’s Switch)?
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.
Sie kommen von den Heartbeats in Opsgenie?
Opsgenie wird am 5. April 2027 abgeschaltet, Heartbeats eingeschlossen. Jeder Heartbeat wird zu einem Healthcheck mit demselben Intervall, und seine Ping-URL ersetzt den Opsgenie-Ping in Ihrem Job. Ein Unterschied: Ein verpasster Lauf alarmiert alle Kanäle gleichzeitig, statt über Ihren Bereitschaftsplan zu gehen. Wenn jemand geweckt werden muss, leiten Sie die Healthcheck-Alarme an PagerDuty weiter. Der Migrationsleitfaden für Opsgenie enthält ein Skript, das alle neu anlegt.
Wie erkenne ich, ob ein Cron-Job fehlgeschlagen ist?
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. Für einen Crontab-Job, der gar nicht läuft, listet cron job not running die üblichen Ursachen auf (auf Englisch).
Was ist eine Karenzzeit beim Cron-Monitoring?
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.
Versteht Hyperping Cron-Ausdrücke und Zeitzonen?
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.
Kann ich sehen, wie lange meine Cron-Jobs dauern?
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.
Kann ich Kubernetes-CronJobs, GitHub Actions oder geplante Windows-Aufgaben überwachen?
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.
Was ist der Unterschied zwischen Cron-Job-Monitoring und Uptime-Monitoring?
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.
Ist Cron-Job-Monitoring kostenlos?
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.
Wie schneidet Hyperping im Vergleich zu Cronitor oder Healthchecks.io ab?
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. Siehe Hyperping vs. Cronitor und Hyperping vs. Healthchecks.io, oder alle Tools im Vergleich unter die besten Tools für Cron-Job-Monitoring.