Heartbeat Monitoring vs Ping Checks: What Each One Actually Sees
A heartbeat monitor waits for your system to contact it and raises an alert when the expected check-in fails to arrive. A ping check does the opposite. It contacts your system on a schedule and alerts when the reply fails to come back. Everything else that separates the two follows from that one difference in direction.
This article works through what that reversal changes in practice: what a ping check can prove and what it structurally cannot, the class of failure only a heartbeat catches, and how the two fit together in a monitoring setup that covers both the things users touch and the things that run quietly in the background. It closes with the sizing question that decides whether a heartbeat is useful or just noisy, which is the interval you choose and the grace period you attach to it.
The direction test, and why it decides everything
The cleanest way to tell these two apart is to ask who opens the connection. In a ping check, or any pull-based check, the monitoring service is the caller. It sends a request from its own infrastructure toward an address you gave it, starts a timer, and judges the response. Your system is passive throughout and does not need to know it is being watched. In a heartbeat monitor, your system is the caller. Your backup script, cron job, or worker finishes its run and sends an HTTP request to a URL the monitoring service gave you. The service is passive and does nothing except note the time.
Call this the direction test, because the direction determines the failure mode each design can detect. A pull check can only see things that answer from a reachable address. A push check can only see things that are capable of speaking up. Each one is blind exactly where the other is not, which is why the honest answer to which should I use is almost always both, applied to different parts of the same system.
What a ping check can see, and what it cannot
A pull check is the right tool for anything with a listening address. Websites, APIs, load balancers, and public endpoints all qualify, and an outside-in check against them proves something genuinely useful: that a real request travelled the real network path and got a real answer. Run from several regions, it also separates a global outage from a routing problem affecting one part of the world, which is a distinction you cannot make from inside your own infrastructure. Our guide to ping tests covers what the underlying request actually measures and where the numbers come from.
The limits appear the moment the thing you care about does not listen on a port. A nightly database backup does not accept connections. Neither does a queue consumer, a billing job, a data export, or a scheduled report. There is no address to check, so a pull check has nothing to reach for. You can approximate coverage by checking a status page the job writes to, but that only proves the status page is up, and a status page frozen on yesterday's success looks identical to one written this morning.
What a heartbeat monitor catches that nothing else does
The heartbeat exists for scheduled work, and the failure it catches is the one that produces no error anywhere: a job that simply never runs. A cron entry deleted during a deploy, a container that failed to restart, a scheduler that lost its lock, a job that ran but exited before its final step. None of these generate an alert on their own, because nothing failed loudly. The work just stopped, and the first sign is usually a person noticing that a report is missing or a backup folder is a week stale. Our guide to cron job monitoring covers the scheduling side of this problem in more depth.
The implementation is deliberately trivial. The monitoring service issues a unique URL, and you add one line at the end of your job that requests it. If the job finishes, the request goes out. If the job never starts, crashes early, or hangs, the request never goes out, and after your configured window the monitor alerts. The mechanism is so small that the temptation is to put the call at the top of the script, where it will fire whether or not the work succeeds. Put it at the bottom, after the last meaningful step, so the heartbeat means completion rather than attendance.
The design choice that matters is the grace period. A job scheduled hourly does not need an alert at sixty-one minutes, because normal variation in start time and runtime will trip it constantly. A reasonable starting point is the expected interval plus the longest observed runtime plus a margin, then tighten it once you have a few weeks of real data. Too tight and the monitor cries wolf until someone mutes it. Too loose and a backup can be dead for a full day before anyone hears about it.
Running both, and where each belongs
The practical split is simple enough to state as a rule. Anything with an address gets a pull check. Anything on a schedule gets a heartbeat. Most real systems have both, and the two together cover a surface that neither covers alone.
Alerting deserves the same split. A failed pull check on a customer-facing endpoint is usually urgent, because users are seeing it now. A missed heartbeat on a nightly report is usually not, because nobody is waiting on it at three in the morning. Routing both into the same channel at the same severity is how teams train themselves to ignore the channel.
Common mistakes in heartbeat monitoring
Putting the ping at the top of the script. A heartbeat fired before the work runs reports attendance, not completion. Move the call to the end, after the last step that has to succeed, so a job that crashes halfway through fails the check instead of passing it.
Setting the grace period to the interval. An hourly job checked at exactly sixty minutes will alert on ordinary variation in start time and runtime. Add the longest observed runtime plus a margin, then tighten once real data exists.
Treating a heartbeat as proof of correctness. The check confirms the script reached its final line. It says nothing about whether the backup contains data or the export contains the right rows. Add an assertion inside the job and only send the heartbeat if it passes.
Assuming a pull check covers background work. An API returning 200 tells you the endpoint answered. Workers behind it can be dead for hours without changing that response, which is exactly the gap a heartbeat is for.
Letting the heartbeat depend on the thing it watches. A heartbeat sent from inside the same container, on the same host, behind the same network path as the job gives you one shared failure mode. The point of the check is to be independent of what it is checking.
FAQ
What is a heartbeat monitor?
A heartbeat monitor is a check that waits for your system to contact it on a schedule and alerts when the expected contact does not arrive. It inverts the usual arrangement, where a monitoring service reaches out to your system, and it exists to watch things that have no address to reach.
How is heartbeat monitoring different from a ping check?
The difference is who initiates. A ping check is pull-based, with the monitoring service sending a request to your server. A heartbeat is push-based, with your job sending a request to the monitoring service. Pull checks watch anything that listens, and heartbeats watch anything that runs.
Is push monitoring better than pull monitoring?
Neither is better, because they detect different failures. Pull monitoring proves an endpoint is reachable from the outside world. Push monitoring proves scheduled work actually completed. Most systems need both, applied to the parts each one can see.
How often should a heartbeat check in?
Match the interval to the job's own schedule, then set the alerting window to that interval plus the longest runtime you have observed plus a margin. An hourly job with a ten minute runtime is reasonably watched at ninety minutes, and you can tighten the window once you have real timing data.
Closing thought
The reason these two checks get confused is that both produce the same output, which is an alert saying something is wrong. They arrive at it from opposite directions, and the direction is the whole design. A pull check answers whether your system responds. A heartbeat answers whether your system acted. Systems fail in both ways, usually at different times, and a monitoring setup that only asks one of those questions will eventually be surprised by the other.
If you are trying to cover both the endpoints users touch and the jobs that run when nobody is watching, Odown handles the pull side with checks that run as often as every minute from seventeen locations on every plan, including the twelve dollar tier. Pair those with a heartbeat on each scheduled job, route the two into different alert channels by urgency, and the gap between the site is up and the work is getting done stops being a gap you find out about from a customer.
