Heartbeat Monitoring Explained — How Push-Based Monitoring Catches What Uptime Checks Miss

Traditional uptime monitoring works by pulling: a service reaches out to your server and checks if it responds. This works well for websites and APIs. It doesn't work at all for background processes.

Heartbeat monitoring flips the direction. Your process pushes a signal to the monitoring service on every successful run. If the signal stops arriving, something is wrong.

Pull vs. push monitoring

Pull-based (traditional uptime monitoring): The monitoring service sends a request → your server responds → monitor records "up."

This model has a blind spot: it can only check things that listen for incoming connections. A cron job doesn't have an HTTP endpoint. A queue worker doesn't accept incoming requests. A backup script runs and exits. Pull-based monitoring can't see any of them.

Push-based (heartbeat monitoring): Your process sends a request → the monitoring service records "alive" → if no request arrives within the expected window → alert.

This model can monitor anything that can make an outbound HTTP request — which is everything. Shell scripts, Python jobs, Lambda functions, Docker containers, systemd timers, CI/CD pipelines.

When to use heartbeat monitoring

Use traditional uptime monitoring for services that are always running and accept connections: websites, APIs, databases, game servers.

Use heartbeat monitoring for everything else:

Cron jobs — the most common use case. Any crontab entry that would cause problems if it stopped running.
Scheduled tasks — systemd timers, Windows Task Scheduler, Kubernetes CronJobs, cloud scheduler functions.
Queue workers and consumers — processes that pull work from a queue. If the worker dies, the queue backs up silently.
Data pipelines — ETL jobs, data syncs, report generators. Stale data is an invisible failure.
Backup systems — daily or hourly backups that must run reliably.
Certificate renewal — Let's Encrypt certbot, ACME clients. Renewal failures are silent until the cert expires.
CI/CD canaries — a scheduled job that deploys a no-op to verify your pipeline still works.

How PoppaPing heartbeat monitoring works

Create a heartbeat monitor and specify:
- Interval — how often you expect the heartbeat (1 minute to 24 hours)
- Grace period — extra time to allow before alerting (for slow runs)

Get your unique URL:

https://poppaping.com/heartbeat/a1b2c3d4-e5f6-7890-abcd-ef1234567890

Ping from your process:
```
curl -fsS https://poppaping.com/heartbeat/YOUR_TOKEN
```
Supports GET, POST, and HEAD. No authentication needed — the token in the URL is the credential.
Get alerted on missed heartbeats via email, Slack, Discord, Telegram, PagerDuty, OpsGenie, or webhooks.

The monitor starts in a "waiting" state until the first heartbeat arrives. After that, the clock is ticking — every interval, the system expects a new ping.

Integration patterns

At the end of a bash script:

#!/bin/bash
set -euo pipefail
# ... your task ...
curl -fsS https://poppaping.com/heartbeat/YOUR_TOKEN

In a Python script:

import requests

def main():
    do_work()
    requests.get("https://poppaping.com/heartbeat/YOUR_TOKEN", timeout=10)

In a Node.js script:

async function main() {
    await doWork();
    await fetch("https://poppaping.com/heartbeat/YOUR_TOKEN");
}

As a one-liner appended to a cron entry:

0 * * * * /opt/scripts/hourly-job.sh && curl -fsS https://poppaping.com/heartbeat/YOUR_TOKEN

The && ensures the heartbeat only fires if the preceding command exits with code 0.

Grace periods: avoiding false alarms

A job that normally takes 2 minutes might take 20 minutes on a bad day. Without a grace period, the monitoring system would alert during every slow run.

Grace periods add a buffer: if your interval is 1 hour and your grace is 15 minutes, the monitor won't alert until 1 hour and 15 minutes have passed since the last heartbeat.

Rule of thumb: Set the grace period to 2-3x your job's worst-case runtime. If the job normally takes 5 minutes but has taken up to 15, set the grace to 30-45 minutes.

Combining push and pull monitoring

The most robust monitoring setup uses both:

Pull (uptime) monitors for your externally-facing services — website, API, status page
Push (heartbeat) monitors for your internal processes — backups, cron jobs, workers, pipelines

Together, they cover both sides of your infrastructure: the parts your users see, and the parts that run invisibly in the background.

PoppaPing supports both in one platform. Uptime monitoring is available on all plans (including free). Heartbeat monitoring is available on paid plans starting at $5/month.