Heartbeat and cron monitoring

A nightly backup, a script that exports invoices every morning at six, a job that clears out old files once a week: processes nobody ever watches, by definition, until the one time they're actually needed and, right then, they're gone.

How it works, in reverse

Every other monitor on this page queries something from the outside and waits for a reply. Heartbeat flips that logic: your process speaks up itself, with a simple call to a dedicated address you've set up for it, every time it finishes its work. If that call doesn't arrive within the expected window, plus a grace period you decide on, the alert fires. There's no outbound request toward your systems at all, which is exactly why it works even for processes sitting behind a firewall, with no public address to reach.

A concrete case

A backup running at home

You wrote a personal script that copies your photo archive to external storage every night. It's worked fine for months, then a system update changes a network path and the script starts failing silently, night after night. No site is involved, so no HTTP monitor would ever notice, and you'd only find out the day you actually need a backup and it isn't there.

A client's nightly cron job

A client has a job that generates the previous day's accounting reports every night and emails them automatically to their accountant. If that job stops running because of a server error, nobody notices until the accountant calls asking where two weeks of data went. A heartbeat on that job would have triggered the alert on the first missed night, not the fourteenth.

Silence as the signal

This feature is built for exactly what a traditional check can't see: not a site answering badly, but a process that has simply stopped talking. Personal project or client work, the principle is the same either way: if something is supposed to happen at regular intervals and at some point it doesn't, you want to know right away, not at the next emergency.