Cron job & heartbeat monitoring
Notice when your backup stops running — not when you need it.
Every monitoring type on this site queries something that answers back. But the things that break most quietly answer nothing at all: the nightly backup, the import job, the queue worker, the cleanup script. They listen on no port and have no URL — they run, or they don't. And when they don't, nobody notices until the backup is needed and the last good copy is six weeks old. Heartbeat monitoring inverts the direction: your job reports to us, and the absence of that report is the alert.
How it works
Each monitor gets its own ping URL when you create it. You call that URL at the end of your job — appending a curl to the crontab line is enough. If the ping arrives within the interval plus the grace you set, the monitor counts as up. If it doesn't, the monitor fires and alerts through the same channels as your other monitors. Because the ping runs after the actual work, a job that aborts never sends one — so you are monitoring success, not just that something started.
When to use it
- Nightly database and file backups
- Cron jobs of every kind, from cleanup scripts to reports
- ETL and import runs between systems
- Queue workers and background processes that can die silently
- Scheduled work in CI, Kubernetes CronJobs or systemd timers
- Field devices that should regularly report they are still alive
What you get
Time since the last ping, uptime ratio and the history of missed runs.
Example
0 3 * * * backup.sh && curl -fsS https://uptimealien.de/ping/…
The blind spot in every uptime monitor
Classic monitoring answers whether a service is running. What it fundamentally cannot answer is whether something that should have happened actually did. A server whose backup cron job has been failing for five weeks on a full disk looks perfectly healthy to any HTTP, TCP or ping check. That is exactly why failed backups are so reliably the worst discovery in operations: the failure isn't loud, it's silent, and you find it at the least convenient moment imaginable.
Fitting it into existing jobs
Integration is deliberately small enough to leave no excuse: you append a curl to the command you already run. What matters is joining it with && rather than a semicolon — that way the ping is only sent when the job finished successfully. A job that aborts with an error sends no ping, and the monitor fires at the expected time. The same works in Kubernetes CronJobs, systemd timers, GitHub Actions workflows and any language that can make an HTTP request.
Choosing the right grace period
Alongside the interval you set a grace period — extra time allowed to pass before a missing ping counts as an outage. It's necessary because scheduled work never runs to the second: the server is busy, the job takes longer depending on data volume, a reboot shifts the schedule. A good rule of thumb is the job's typical runtime plus some headroom. Set it too tight and ordinary jitter wakes you; set it too generously and you lose time you could have spent fixing the problem.
Frequently asked questions
What is heartbeat monitoring?
An inverted check, also called a dead man's switch: instead of a monitor querying your service, your job reports to UptimeAlien after each successful run. If that report stops arriving, an alert fires.
How do I connect a cron job?
Append a curl call to the ping URL to your existing command, joined with &&. No SDK or installation is needed — you'll find the URL on the monitor's detail page.
Will it catch a job that starts but then fails?
Yes, as long as you append the ping with &&. It is then only sent on successful completion; an abort means no ping arrives and the monitor fires.
What is the grace period for?
Scheduled work never runs exactly on beat. The grace is the extra time beyond the interval that may pass before a missing ping counts as an outage — without it, ordinary jitter would fire alerts constantly.
Is the ping URL secret?
Yes, treat it like a password. It contains a random token and is the only credential needed to report in. Anyone who knows it can mark the monitor green — but nothing more: it grants no read or write access.
What happens if I pause the monitor?
Incoming pings are still recorded. That way the monitor doesn't retroactively report an outage for the stretch it was paused when you resume it.