Heartbeat Monitoring: What It Is, How It Works, and Best Tools in 2026

What is heartbeat monitoring?

Heartbeat monitoring is an inverted approach to service health checks. Instead of an external monitor polling your service, your service pings the monitor on completion. If the expected ping does not arrive within a configurable time window, the monitoring service alerts your team.

The name comes from the analogy of a heartbeat: as long as the signal keeps coming, everything is fine. When it stops, something is wrong. In distributed systems, this pattern is also called a dead man's switch — the alarm fires when the expected signal is absent, not when an error is present.

Heartbeat monitoring vs. uptime monitoring

The two approaches are complementary, not interchangeable:

What to use heartbeat monitoring for

Any process that should run on a predictable schedule and whose failure would not immediately surface to users is a candidate for heartbeat monitoring. Common examples:

Database backups

A database backup cron that fails silently is one of the most dangerous possible failures — you will not discover it until you need to restore. Adding a heartbeat ping at the end of your backup script ensures you know within hours if the backup stopped running.

Payment and billing jobs

Subscription billing retries, invoice generation, and payment failure handling are typically background jobs. If the queue worker crashes or the cron never triggers, customers are not charged and revenue silently stops. Heartbeat monitoring catches this before finance notices the drop.

Data sync and ETL pipelines

Nightly sync jobs that pull from external APIs, transform data, and load into your warehouse run silently. If they stop running, dashboards show stale data — and data teams often notice only when stakeholders ask questions about numbers that have not moved.

Email and notification queues

Background workers that process email sends, push notifications, or webhook deliveries can stall without visible symptoms. Users stop receiving emails, but no error page appears. Heartbeat monitoring detects the dead queue before customer complaints flood in.

SSL certificate renewals (Let's Encrypt)

Certbot and other ACME clients run as cron jobs. If the renewal cron fails, your certificate will expire 90 days later — and you might not notice until the browser warning appears. A heartbeat monitor on your renewal script catches renewal failures weeks before the cert expires. Pair this with SSL certificate monitoring for full coverage.

How heartbeat monitoring works

1. Create a monitor with an expected interval

In your heartbeat monitoring tool, create a new monitor and configure the expected check-in interval — for example, every 24 hours. Most tools let you specify a grace period: how much late is acceptable before an alert fires. A nightly job might have a 1-hour grace period. A critical real-time job might have a 5-minute grace.

2. Get a unique ping URL

The tool gives you a unique HTTPS URL for each monitor. This URL accepts GET or POST requests — hitting it registers a successful heartbeat for that monitor.

3. Add the ping to your job

At the end of your cron job or background task, send a GET request to the ping URL. Most curl commands look like this:

#!/bin/bash
# Run your backup job
pg_dump mydb > /backups/mydb_$(date +%Y%m%d).sql

# If backup succeeded, ping heartbeat monitor
if [ $? -eq 0 ]; then
  curl -fsS --retry 3 https://hc-ping.com/your-monitor-uuid > /dev/null
fi

For Python, Node.js, or other languages, a simple HTTP GET to the ping URL achieves the same result:

# Python example
import requests

def run_backup():
    # ... your job logic ...
    pass

if __name__ == "__main__":
    try:
        run_backup()
        # Ping heartbeat on success
        requests.get("https://hc-ping.com/your-monitor-uuid", timeout=10)
    except Exception as e:
        # Optionally ping with /fail to mark failure immediately
        requests.get("https://hc-ping.com/your-monitor-uuid/fail", timeout=10)
        raise

4. Configure alerts

When the heartbeat window expires without a ping, the monitoring service sends alerts to your configured channels — email, Slack, PagerDuty, webhook, or SMS depending on your tool and plan.

5. Monitor the monitor

Some platforms also let you start a timer at the beginning of a job and ping on completion, giving you job duration tracking alongside availability monitoring. If a job that normally takes 5 minutes starts taking 45 minutes, that is itself a signal worth alerting on.

Common heartbeat monitoring mistakes

Pinging before the job completes

Always send the heartbeat after your job logic runs successfully, not before. Pinging at the start of the script only tells you the script launched — not that it completed.

Not handling errors separately

If your job fails halfway through, it should not ping the heartbeat URL. Use conditional pings (only ping on success) or use dedicated “success” and “fail” endpoints if your tool supports them.

Setting the interval too tight

If your job runs in a variable amount of time, setting a very short grace period leads to false alerts. Set the grace period to account for the worst-case legitimate runtime plus some buffer.

Monitoring only the trigger, not the completion

Some teams monitor whether a cron job was triggered (e.g., a Lambda invocation fired) rather than whether the job completed successfully. Trigger monitoring only tells you the scheduler worked — it does not catch code failures, timeouts, or partial execution.

Best heartbeat monitoring tools in 2026

Heartbeat monitoring for specific cron patterns

Linux/Unix cron

Add a curl ping at the end of your crontab entry or shell script. Use the --retry flag to handle transient network failures without false missed-heartbeat alerts:

# Crontab entry: run backup daily at 2am, ping on success
0 2 * * * /opt/scripts/backup.sh && curl -fsS --retry 3 https://hc-ping.com/uuid

GitHub Actions scheduled workflows

Add a final step to your workflow that pings the heartbeat URL after all other steps succeed:

- name: Ping heartbeat monitor
  if: success()
  run: curl -fsS --retry 3 ${{ secrets.HEARTBEAT_URL }}

AWS Lambda scheduled functions

At the end of your Lambda handler, send an HTTP request to the ping URL. Using an HTTP client with a short timeout prevents the Lambda from hanging on the ping:

import urllib.request

def handler(event, context):
    # ... your logic ...

    # Ping heartbeat on success
    urllib.request.urlopen(
        os.environ["HEARTBEAT_URL"],
        timeout=5
    )

Frequently asked questions

What is heartbeat monitoring?

Heartbeat monitoring is a technique where your process sends a periodic ping to an external monitoring service on completion. If the expected ping is not received within a configured time window, the monitoring service triggers an alert. It is the standard approach for detecting silent failures in cron jobs, background workers, and scheduled tasks that have no HTTP endpoint to probe externally.

What is the difference between heartbeat monitoring and uptime monitoring?

Uptime monitoring is pull-based: the monitor calls your service. Heartbeat monitoring is push-based: your service calls the monitor. Uptime monitoring works for web servers and APIs. Heartbeat monitoring works for internal cron jobs and background processes. Both are necessary for comprehensive observability.

What should I use heartbeat monitoring for?

Cron jobs, database backups, ETL pipelines, payment retry queues, email worker processes, SSL renewal scripts, and any scheduled task whose failure would not immediately surface as a visible error to users.

What is the best free heartbeat monitoring tool?

Healthchecks.io offers a generous free tier (20 monitors) with no credit card required. Better Stack includes heartbeat monitoring in its free tier. APIStatusCheck bundles heartbeat monitoring with uptime and API monitoring.

How does a dead man switch monitor work?

A dead man switch monitor sets a timer that resets each time a ping arrives. If the timer expires — because no ping arrived within the expected window — the monitoring service treats it as a failure and fires an alert. The job does not need to report errors; the absence of a success ping is itself the failure signal.