Jeder Cron-Job-Monitor hat eine eigene Ping-URL, die auf seiner Seite angezeigt wird. Ersetzen Sie https://app.uptimecheck.com/api/hb/your-token unten durch Ihre. Wie Sie den Monitor anlegen, lesen Sie unter Cron-Job überwachen.
Die URLs
…/your-token: Der Job ist gelaufen und war erfolgreich.…/your-token/start: Der Job hat begonnen. Sie sehen die Laufzeiten, und ein Lauf, der die Maximum run time überschreitet, löst einen Alarm aus.…/your-token/fail: Der Job ist fehlgeschlagen. Sie werden sofort alarmiert statt erst zur Frist.…/your-token/0 bis /255: der Exit-Code. 0 bedeutet Erfolg, alles andere einen Fehler.
GET, POST und HEAD funktionieren gleichermaßen, die Antwort lautet OK. Ein POST-Body wird als Ausgabe des Jobs gespeichert und bei Fehlern sowie im Alarm angezeigt. Wir lesen bis zu 64 kB und behalten den Anfang und das Ende, insgesamt 10.000 Zeichen. Ein größerer Body wird abgelehnt und der Ping geht verloren, senden Sie also das Ende des Logs, wie unten gezeigt. Das Token in der URL ist das Geheimnis, halten Sie es daher aus öffentlichen Logs heraus.
Ein Wrapper für jeden Scheduler
Dieses Skript führt einen Befehl aus, meldet dessen Start, den Exit-Code und die letzten 60 kB der Ausgabe und gibt den Exit-Code weiter. Speichern Sie es als /usr/local/bin/with-ping und führen Sie chmod +x darauf aus.
#!/bin/sh
# with-ping URL COMMAND…: runs COMMAND and reports it to Uptimecheck
url=“$1″; shift
curl -fsS -m 10 –retry 3 -o /dev/null „$url/start“
log=$(mktemp)
„$@“ > „$log“ 2>&1
code=$?
tail -c 60000 „$log“ | curl -fsS -m 10 –retry 3 –data-binary @- -o /dev/null „$url/$code“
rm -f „$log“
exit $code
crontab
# Ping when the job succeeds
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
# Or report start, exit code and output with the script above
0 3 * * * /usr/local/bin/with-ping https://app.uptimecheck.com/api/hb/your-token /usr/local/bin/backup.sh
Geben Sie dem Monitor denselben Zeitplan und die Time zone, in der die crontab läuft, oft UTC.
Laravel Scheduler
Laravel pingt URLs selbst. In routes/console.php (ab Laravel 11; davor dieselben Methoden auf $schedule in app/Console/Kernel.php):
use Illuminate\Support\Facades\Schedule;
Schedule::command(„backup:run“)
->dailyAt(„03:00“)
->pingBefore(„https://app.uptimecheck.com/api/hb/your-token/start“)
->pingOnSuccess(„https://app.uptimecheck.com/api/hb/your-token“)
->pingOnFailure(„https://app.uptimecheck.com/api/hb/your-token/fail“);
Als Fehler gilt ein Befehl, der mit einem Exit-Code ungleich null endet. Der Zeitplan folgt der Zeitzone der App, sofern Sie nicht ->timezone() ergänzen; stellen Sie dieselbe am Monitor ein.
Kubernetes CronJob
Speichern Sie die Ping-URL als Secret mit kubectl create secret generic uptimecheck –from-literal=ping-url=https://app.uptimecheck.com/api/hb/your-token. Das Image braucht curl.
apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-backup
spec:
schedule: „0 3 * * *“
timeZone: „Europe/Stockholm“
concurrencyPolicy: Forbid
jobTemplate:
spec:
backoffLimit: 0
template:
spec:
restartPolicy: Never
containers:
– name: backup
image: registry.example.com/backup:1.4
env:
– name: PING_URL
valueFrom:
secretKeyRef:
name: uptimecheck
key: ping-url
command: [„/bin/sh“, „-c“]
args:
– |
curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL/start“
/app/backup.sh > /tmp/out.log 2>&1
code=$?
tail -c 60000 /tmp/out.log | curl -fsS -m 10 –retry 3 –data-binary @- -o /dev/null „$PING_URL/$code“
exit $code
Startet der Pod gar nicht, etwa weil das Image nicht geladen werden kann, kommt kein Ping an und der Monitor alarmiert zur Frist. timeZone erfordert Kubernetes 1.27 oder neuer.
GitHub Actions
on:
schedule:
– cron: „0 3 * * *“
jobs:
nightly:
runs-on: ubuntu-latest
env:
PING_URL: ${{ secrets.UPTIMECHECK_PING_URL }}
steps:
– uses: actions/checkout@v4
– run: curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL/start“ || true
– run: ./scripts/nightly.sh
– if: success()
run: curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL“
– if: failure()
run: curl -fsS -m 10 –retry 3 -o /dev/null „$PING_URL/fail“
Speichern Sie die Ping-URL als Repository-Secret UPTIMECHECK_PING_URL. Geben Sie dem Monitor die Zeitzone des Workflows, standardmäßig UTC. Bei hoher Auslastung startet GitHub geplante Läufe mitunter verspätet, planen Sie also eine großzügige Grace period ein, etwa 30 Minuten.
systemd-Timer
# /etc/systemd/system/backup.service
[Unit]
Description=Nightly backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/with-ping https://app.uptimecheck.com/api/hb/your-token /usr/local/bin/backup.sh
# /etc/systemd/system/backup.timer
[Unit]
Description=Run the nightly backup
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
Aktivieren Sie ihn mit sudo systemctl daemon-reload und sudo systemctl enable –now backup.timer. OnCalendar folgt der Zeitzone des Servers.
Windows-Aufgabenplanung
# C:\Scripts\backup-with-ping.ps1
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$ping = „https://app.uptimecheck.com/api/hb/your-token“
try { Invoke-RestMethod -Uri „$ping/start“ -TimeoutSec 10 | Out-Null } catch {}
$output = & „C:\Scripts\backup.cmd“ 2>&1 | Out-String
$code = $LASTEXITCODE
if ($output.Length -gt 30000) { $output = $output.Substring($output.Length – 30000) }
Invoke-RestMethod -Uri „$ping/$code“ -Method Post -Body $output -TimeoutSec 10 | Out-Null
exit $code
Registrieren Sie es in PowerShell als Administrator, sodass es jede Nacht um 03:00 Uhr läuft:
$action = New-ScheduledTaskAction -Execute „powershell.exe“ -Argument „-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\backup-with-ping.ps1“
$trigger = New-ScheduledTaskTrigger -Daily -At 3am
Register-ScheduledTask -TaskName „Nightly backup“ -Action $action -Trigger $trigger -User „SYSTEM“ -RunLevel Highest
Die Aufgabenplanung nutzt die Zeitzone des Computers; stellen Sie dieselbe am Monitor ein. Mehr zu Cron-Ausdrücken und zum Cron-Job-Monitoring.