CronPupHeartbeat monitoring vs uptime monitoring: what each one catches
Most teams already have uptime monitoring: a service requests your homepage or API every minute and alerts when it fails. That's the right tool for things that are supposed to be reachable. It's the wrong tool for things that are supposed to happen, like backups, reports, data syncs, queue workers and certificate renewals.
| Uptime (synthetic) monitoring | Heartbeat monitoring | |
|---|---|---|
| Who sends the request | The monitor calls your service | Your job calls the monitor |
| What it proves | An endpoint answered | A job ran (and succeeded) on schedule |
| Catches | Outages, slow responses, bad deploys | Jobs that never ran, failed, or hung |
| Works behind firewalls | No, it needs a public endpoint | Yes, it only needs outbound HTTPS |
| Typical targets | Websites, APIs | Cron, backups, ETL, workers, CI schedules |
Why uptime checks miss job failures
When the nightly backup doesn't run, every endpoint is still up. There is no error to observe, only something missing. A heartbeat flips the check around: the job reports in, and silence is the alarm. That's also why heartbeats work for jobs on private networks. They only need to make one outbound request.
Do you need both?
Usually, yes. Uptime monitoring for your public surface, heartbeats for everything scheduled or asynchronous. CronPup does the heartbeat side, plus TLS expiry checks. If you also want uptime checks from one vendor, a broader platform may suit you better. See the comparison.
Getting started
0 3 * * * /opt/jobs/backup.sh && curl -fsS -m 10 https://cronpup.com/p/YOUR-UUIDCreate a free account (10 monitors) and add that one line.