Heartbeat monitoring: cron jobs and automated processes

A nightly backup, a script that exports invoices every morning, a scheduled job (often called a "cron job", after the program that runs them at fixed times) that clears out old files once a week: processes nobody ever watches, by definition, until the one time they're actually needed.

Every other monitor type described on these pages queries something from the outside and waits for a reply. Heartbeat, literally a "heartbeat", flips that logic: your process speaks up itself, with a call to a dedicated address 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. No request ever goes out to your systems, so it works even behind a firewall, and the authentication secret is shown once, when the monitor is created.

Two concrete cases

A personal script copies a 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 it's only discovered the day a backup is actually needed and isn't there.

A similar case, on a different scale: a job that generates the previous day's accounting reports every night and emails them to the accountant. If it 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 triggers the alert on the first missed night, not the fourteenth.

Self-service or assisted setup

Wiring a heartbeat into an existing script means adding one line of code that calls the assigned address once the job finishes. If you're not sure how to do that in your case, or you don't have direct access to the script, the Etizei team can help you set it up: we just need to know what the job does and how often it should run.