What Is Heartbeat Monitoring? Uptime Checks for Background Jobs

Most uptime monitoring works by probing your service from the outside — an external server sends a request and waits for a response. This works well for websites and APIs. But what about background jobs, cron tasks, and worker processes that don't expose an HTTP endpoint?

Heartbeat monitoring (also called dead man's switch monitoring or cron job monitoring) flips the model around: instead of the monitor probing your service, your service pings the monitor on a regular schedule. If the check-in stops arriving, the monitor raises an alert.

The Problem Heartbeat Monitoring Solves

Consider a background job that runs every night at midnight to process customer data, send emails, or run database maintenance. Traditional HTTP uptime monitoring can't check this — there's no URL to hit. The only way to detect failure is by its absence: if the job doesn't run, no one knows until downstream problems surface hours or days later.

Without heartbeat monitoring, you discover cron failures when:

• A customer complains that their scheduled report never arrived
• A database table fills up because cleanup jobs stopped running
• You realise weekly backups haven't run in three weeks

Heartbeat monitoring catches these failures immediately, at the next expected check-in interval that gets missed.

How Heartbeat Monitoring Works

1. You create a heartbeat monitor with a unique ping URL and an expected interval (e.g., "check in every 24 hours")
2. Your cron job or background task sends an HTTP request to that URL at the end of each successful run
3. The monitoring service waits for the expected interval plus a grace period
4. If no ping arrives, an alert fires

The "success ping" is typically a simple HTTP GET or POST request to a URL like:

https://monitoring-service.com/heartbeat/abc123

Your cron job or script makes this request at the end of a successful run. If the job crashes, is skipped, or takes too long, the ping never arrives.

What to Monitor with Heartbeats

Heartbeat monitoring is suited for any repeating task that must run on a schedule:

Database tasks:

• Nightly database backups
• Database vacuum / cleanup jobs
• Data migration scripts

Application tasks:

• Email sending queues
• Report generation jobs
• Order processing workers
• Payment retry queues
• Cache warming jobs

Infrastructure tasks:

• Log rotation
• Certificate renewal scripts
• Backup verification

Data pipelines:

• ETL processes
• API sync jobs
• Analytics aggregation

If any of these stop running and no one notices for days, heartbeat monitoring fills that gap.

Heartbeat Monitoring vs. Uptime Monitoring

Both types are complementary. A complete monitoring setup includes uptime monitoring for your public-facing endpoints and heartbeat monitoring for your background processes.

Setting Up Heartbeat Monitoring

1. Create a Heartbeat Monitor

In your monitoring tool, create a new heartbeat (or "cron job") monitor and specify:

• Expected interval — how often should the job check in? (e.g., every 1 hour, every 24 hours)
• Grace period — how long after the expected time to wait before alerting (e.g., 15 minutes)
• Alert channels — where to send alerts when a heartbeat is missed

You'll receive a unique ping URL for this monitor.

2. Add the Ping to Your Job

At the end of your cron job or background task, add a call to the ping URL:

Shell script:

# Your job logic here
./run_backup.sh && curl -s "https://your-monitor/heartbeat/abc123"

Python:

import requests
# Your job logic here
run_backup()
requests.get("https://your-monitor/heartbeat/abc123")

Node.js:

// Your job logic here
await runBackup();
await fetch("https://your-monitor/heartbeat/abc123");

The key pattern is: only ping if the job succeeded. If run_backup.sh fails, the && prevents the ping, which correctly triggers a missed heartbeat alert.

3. Configure Alerts

Set up alerts to fire when a heartbeat is missed — the same channels you use for your uptime alerts: email, SMS, Slack.

Domain Monitor includes cron job / heartbeat monitoring as part of its monitoring suite. See introducing cron monitoring for how it works in practice.

Grace Periods

The grace period is important. Cron jobs occasionally run slightly late due to system load — a job scheduled at midnight might not start until 12:02am. Setting a grace period of 15-30 minutes prevents false alarms from these minor delays while still catching genuine failures.

Set your grace period based on your job's typical variance:

• Tight jobs (run every minute) — 2-3 minute grace period
• Hourly jobs — 15 minute grace period
• Daily jobs — 30-60 minute grace period

Heartbeat Monitoring for AI Agents

AI agent workflows often involve scheduled tasks — automated agents that run at specific intervals to process data, check for updates, or trigger actions. Heartbeat monitoring is ideal for these workflows:

• An AI agent that scrapes and summarises news every hour should ping a heartbeat monitor each time it completes
• An agent that sends scheduled AI-generated reports should confirm successful completion
• MCP server health checks can be configured as heartbeats

This gives you visibility into whether your AI automation is actually running on schedule, not just whether the underlying server is up.

The Silent Failure Problem

Background jobs fail silently more often than any other class of software. There's no user seeing an error, no server returning a 500, no alert from your hosting provider. The only evidence is an absence — something that should have happened, didn't.

Heartbeat monitoring converts this absence into a signal. It's the difference between discovering a three-week backup failure when you need to restore data, and getting an alert on night one.

Add heartbeat monitoring for your cron jobs at Domain Monitor.

Related Articles

• "Monitoring Background Jobs and Scheduled Tasks"
• "Uptime Monitoring Best Practices: A Complete Guide"
• "Uptime Monitoring for AI Applications and LLM APIs"