Monitor cron jobs, backup scripts and background processes passively. Push monitoring flips the normal monitoring logic — your script reports to Uptime Kuma, not the other way round. Perfect for UK cron jobs, scheduled backups and any task that runs silently.
What Push monitoring is • Push vs active monitoring • Creating a Push monitor step by step • The Push URL and optional parameters • Practical use cases • Monitoring a daily backup example • Choosing the right timeout • FAQ
Most monitor types actively reach out to a service. Push monitoring flips this: instead of Uptime Kuma checking your service, your service sends a heartbeat to Uptime Kuma. If the heartbeat stops arriving within a defined timeout, the monitor is marked down and notifications fire.
Ideal for processes that run in the background and can’t be polled from outside — cron jobs, scheduled backups, batch imports, database maintenance scripts, any task that runs on a timer.
https://your-instance.uptimekuma.io/api/push/abc123curl -s https://your-instance.uptimekuma.io/api/push/abc123Every Push monitor gets a unique URL. Your script calls it with any HTTP client — curl, wget, PowerShell Invoke-WebRequest, Python requests, browser fetch. Both GET and POST are accepted.
Optional query parameters:
?status=up — explicitly report success (default)?status=down — explicit failure, monitor marked down immediately without waiting for timeout?msg=Backup+completed — short message visible in heartbeat history?ping=350 — custom response time in ms, useful for tracking job durationTip: combine: curl -s "URL?status=up&msg=Backup+done&ping=4500". Gives complete history of job execution times and outcomes.
Practical example: database backup script runs every night at 03:00 AM via cron.
curl -s "https://your-instance.uptimekuma.io/api/push/abc123?status=up&msg=Backup+completed"From now on, if backup fails, hangs, or cron daemon stops running, heartbeat never arrives. After 25 hours Uptime Kuma marks monitor down and sends notifications.
Important: Push monitors rely on your script calling the URL. If the script itself fails before reaching the curl line, the heartbeat is never sent — which is exactly what you want to detect. Always place the heartbeat call as the last command, after all critical operations have completed successfully.
Most important setting for Push. Too short = false alerts. Too long = real failures go unnoticed. Rule of thumb: expected interval + 10–25% grace.
| Job frequency | Timeout |
|---|---|
| Hourly | 4,200 seconds (70 minutes) |
| Every 6 hours | 25,200 seconds (7 hours) |
| Daily | 90,000 seconds (25 hours) |
| Weekly | 648,000 seconds (7.5 days) |
Grace accounts for natural variation — a backup that usually takes 10 minutes might occasionally take 30.
Monitor every cron job for £1/month
Unlimited Push monitors on SmartXHosting Uptime Kuma Hosting — scheduled tasks, backups, batch jobs, wp-cron. All on UK infrastructure with daily backups.
View Uptime Kuma HostingQ: What is Push monitoring?
A: Passive — your script sends heartbeats to Uptime Kuma. No heartbeat within timeout = down + notification.
Q: Push vs HTTP?
A: HTTP = active (Uptime Kuma polls). Push = passive (script reports). Use Push for jobs that can’t be polled.
Q: Can I monitor a cron job?
A: Yes. Add curl to Push URL at end of cron script. If cron fails, heartbeat stops, alert fires.
Q: What if script fails before heartbeat?
A: Heartbeat never sent, monitor goes down — exactly what you want to detect failure.
Q: Timeout for daily job?
A: 86,400 seconds (24h) + 1–2h grace. 90,000 seconds (25h) is a safe default.
Q: Can I send heartbeat from Windows?
A: Yes — PowerShell Invoke-WebRequest -Uri "URL" or wget, curl.exe, or any HTTP client.