Cron job & heartbeat monitoring that catches silent failures.
A dead cron job throws no error and writes no log — you find out when you need the backup. Give each job a ping URL and Uptimia opens an incident within a minute of the missed deadline.
Pulse — last 2 hours
one blip per ping received · 24 expectedHow this check works
hb_9f2c41d8a03b57e6The ping — one line of cron
crontab · queue-workerPing log
every signal we received, newest firstThe backup that didn't run
A nightly database backup, scheduled for 03:30. The script died before it could ping — nothing errored, nothing logged, and the only signal was the ping that never arrived.
Monitor scheduled jobs wherever they run
If it can send an HTTP request, Uptimia can watch it — pings are outbound-only, so firewalled and NAT jobs report in fine.
Schedules, signals and the ping log
Alerted within a minute
Every monitor is checked every 60 seconds. A missed deadline past your grace opens one incident and alerts go out — no repeat storms, and it closes only when a real ping returns.
- Escalation ladders and one-click acknowledgement links — no login needed
- Recovery notice when the job comes back
- Maintenance windows and pause — no false alerts during deploys
Your cron expression, your timezone
Paste the line already sitting in your crontab, or set a plain interval from 30 seconds to 90 days. Deadlines shift with DST, so a 03:30 job stays a 03:30 job through October.
- Any five-field cron expression — ranges, steps, names, @daily-style macros
- A grace period you set per job — one that sometimes runs long won't page anyone
- Invalid or impossible schedules rejected at save
your TZ
Every run in the ping log
Open a monitor and see when the job last ran, whether it has been drifting later week on week, and how long each run took — without shelling into the box.
- 12-hour pulse strip and a pings-per-hour chart against the expected rate
- Run duration on every ping when the job sends a start signal
- Late pings flagged in the log — never paged
expected 4 / hour — 09:00 got 3
start 09:45:01 · success 09:45:03 → run 2.1 s
Catches hangs and crashes, not just silence
Three signals cover every way a job can fail. Success resets the countdown; start enables a runtime cap, so a hung job alerts even if it never exits; fail alerts immediately.
- /start — run duration in the log, plus maximum-runtime detection
- /fail — immediate incident, grace skipped
- GET, POST or HEAD — curl, wget, or any HTTP client
modes
How heartbeat monitoring works
One URL per job — no agent, no library.
Create a monitor
Name the job and set its schedule — interval or cron. Saving generates a private ping URL.
Add one line to the job
Append a curl, or copy a ready-made snippet — Crontab, Bash, PowerShell, GitHub Actions or PHP. The monitor arms itself on the first ping.
30 3 * * * /usr/local/bin/db-backup.sh \
&& curl -fsS -m 10 --retry 3 \
https://uptimia.com/p/hb_9f2…c41 >/dev/null
# first real ping arms the monitor:
✓ ping received — db-backup · nightly is armed
Get alerted when it goes quiet
Missed deadline plus grace = one incident. Your team is alerted within a minute, on the channels you already use.
Add one line to the job.Hear about it the night it stops.
Every job, every ping, every alert channel — free for 30 days, and none of it is a paid add-on.
Also included
Full REST API
Create, edit, pause and delete heartbeats from your pipeline — plus a cron-preview endpoint that validates expressions before they ship.
Snippets with your token filled in
Crontab, Bash, PowerShell, GitHub Actions and PHP.
One-click token reset
The old URL dies the moment you regenerate.
NAT-friendly rate limits
Counted per monitor, not per IP — worker fleets welcome.
Test pings
Fire one from the panel to see it land in the log.
Every monitor type in one account
The same groups, the same contact list and the same roles as every other monitor type.
Where your alerts land
A missed backup reaches the same people, on the same channels, as a site that went down.
Microsoft Teams12 channels, one contact list — set it once, every monitor type uses it.
Browse the full integrations directory →What is cron job & heartbeat monitoring?
Cron job monitoring — also called heartbeat monitoring — checks that scheduled tasks actually run. Instead of Uptimia probing your server, each job sends a short HTTP request ("ping") to its own unique URL when it runs. If the ping doesn't arrive on schedule plus grace, Uptimia opens an incident and alerts you.
Uptime monitoring
Works when there's something to ask. Websites and APIs answer; a cron job doesn't.
Heartbeat monitoring
no ping by 03:32 → incident opens · a /fail ping alerts instantly
A dead man's switch for cron
Every Uptimia heartbeat monitor is one — cron-aware schedules, a grace period, and alerts wherever your team works.
Heartbeat monitoring FAQ
01What does my job actually have to do?+
curl -fsS -m 10 --retry 3 https://uptimia.com/p/hb_… at the end of the crontab line is enough. GET, POST and HEAD all work. The monitor stays dormant until its first real ping, so it can't alert while you're wiring it up.02When exactly does an alert fire?+
/fail ping alerts immediately, and nothing re-alerts while an incident is open.03My job hangs instead of crashing — will you catch that?+
/start when the run begins and set a maximum runtime. If no success follows within the cap, an incident opens. You also get each run's duration in the log.04Why didn't my cron job run?+
05Can I monitor Kubernetes CronJobs, GitHub Actions, or Windows tasks?+
06What do you store about each ping?+
07We ping from hundreds of workers behind one NAT — is that a problem?+
08Which timezone do cron schedules run in?+
09Can I manage heartbeats without the UI?+
10Can a link preview accidentally keep a dead job looking alive?+
11Is heartbeat monitoring a paid add-on?+
Start monitoring your cron jobs today.
One line at the end of a job puts it under watch — beside your uptime, SSL and server monitoring.