What Is a Heartbeat Monitor?

Some failures don't make noise. A cron job stops running. A queue worker exits quietly. Your site stays up, your API responds, and no alert fires. Nobody finds out until the backup is gone or the nightly report didn't run. A heartbeat monitor is how you catch those.

How it works

A regular uptime check works by a monitor reaching out to your server and checking for a response. A heartbeat monitor works the other way: your job reaches out to ServerVisor. At regular intervals, your script sends a simple HTTP request to a unique ping URL. If that ping stops arriving within the expected window, ServerVisor sends you an alert. It's a dead man's switch - if the script stops sending the signal as it should, we assume it's dead.

There's nothing to expose on your server. No port needs to be open. ServerVisor waits, and the absence of that signal is the failure.

What it catches that uptime checks miss

Uptime checks tell you whether a URL is reachable. They say nothing about what's running behind it. Heartbeat monitors cover:

• Cron jobs: daily backups, report generators, data sync tasks
• Queue workers: background processors that consume jobs from a queue
• Scheduled scripts: anything that runs on a timer rather than in response to a request
• Internal health routines: jobs that verify system state and write results somewhere

Setting one up

When you create a heartbeat monitor, you set two things: the expected period and a grace period. The period is how often your job should run. The grace period is extra buffer before the alert fires, giving the job time to finish.

When you set up a heartbeat monitor in ServerVisor, you get a ping URL. Add a single line to your job that calls that URL after the work is done.

Sending the ping

Put the ping at the very end of your job, after all the work completes. If the job fails partway through, the ping never fires and the monitor alerts you.

From a shell script or cron job:

# Do the work, then ping on success
/usr/local/bin/run-backup.sh && curl -fsS --retry 3 https://servervisor.io/ping/your-unique-token > /dev/null

From a Python script:

import requests

def run_backup():
    # your backup logic
    pass

if __name__ == "__main__":
    run_backup()
    requests.get("https://servervisor.io/ping/your-unique-token", timeout=10)

The pattern is the same in any language: do the work, then call the URL. Keep the ping call outside any try/except that swallows errors — a failed job should not ping.

When a ping is missed

When the grace period expires without a ping, ServerVisor alerts you through your configured channels: email, SMS, push notification, or webhook. The alert tells you which monitor missed and when the last successful ping arrived, so you know which job stopped and roughly when.

Once the job runs again, the monitor recovers automatically on the next successful ping. No manual reset needed.

When to add one

Any job where a silent failure would go unnoticed is a candidate. If someone would only find out days later, when a report is missing or data is stale, add a heartbeat monitor. Uptime checks and heartbeat monitors do different things: one watches that your services are reachable, the other watches that your jobs are actually running.