---
title: "What is heartbeat monitoring? | Logdash"
description: "Heartbeat monitoring for software: the job pings the monitor, silence trips the alert. A worker loop you can paste, how it works with cron, and where it falls short."
url: https://logdash.io/learn/what-is-heartbeat-monitoring
---

# What is heartbeat monitoring

Heartbeat monitoring turns the usual uptime check around: your job or worker calls a monitor URL every time it finishes a unit of work, and the monitor alerts you when those calls stop arriving.

An HTTP uptime check asks your server a question every few minutes. That works for anything with a URL. A queue worker, a backup script, a data sync or a cron job has no URL to ask. It runs in the background, and when it dies it dies quietly: no 500, no error page, often no log line, just work that stops getting done. Heartbeat monitoring exists for that silence.

## How a heartbeat check works

- The monitor gives you a unique URL. In Logdash it is a POST to api.logdash.io/ping/ followed by the monitor id, public, with no auth header and no body.
- Your process calls that URL each time it completes a pass of real work.
- The monitor keeps a window. A call inside the window means alive. An empty window means down, and the alert fires on that change.
- When the calls come back, the monitor flips to up and tells you that too.

One design rule matters more than the tool: ping after the work, not on a timer beside it. A background thread that pings every 10 seconds while the main loop is stuck on a dead database connection reports healthy for the whole outage. A ping that only happens when a pass completes cannot lie that way.

## Heartbeat monitoring software in practice

Logdash push monitors use a 15-second window on the Pro plan. That makes them a fit for things that run all the time: queue consumers, pollers, sync loops, websocket servers. This is the whole integration for a worker written as a shell loop:

 worker.sh 

```bash
#!/usr/bin/env bash
# worker.sh - one pass of real work, then one heartbeat, forever.
set -euo pipefail

PING_URL="https://api.logdash.io/ping/${LOGDASH_MONITOR_ID}"

while true; do
  /srv/app/bin/process-queue   # a failed pass ends the loop, so the pings stop
  curl -fsS -m 5 -X POST "$PING_URL" > /dev/null || true
  sleep 5                      # one pass plus the sleep must fit in 15 seconds
done
```

If process-queue exits non-zero, set -e ends the loop, the pings stop, and the next empty window marks the monitor down. If it hangs, same result. The || true on curl means a network blip on the ping itself never kills the worker. The endpoint allows 300 calls a minute per IP, so a ping every few seconds is nowhere near the limit.

## Heartbeat monitoring for cron

A cron job is the textbook heartbeat case: append a curl to the crontab line with && so only a successful run reports in. The catch is the window. An hourly job needs a monitor that knows "hourly" and adds a grace period. Logdash does not. It expects a call in every 15-second window, so an hourly job would read as down for 59 minutes of every hour and alert you twice an hour. The cron monitoring explainer shows the HTTP check that works instead.

## Heartbeat check vs uptime check

Most apps need both. An uptime check asks from outside whether the front door opens. A heartbeat asks from inside whether the work gets done. Your API can return 200 all week while the worker that sends receipts has been dead since Tuesday.

### Logdash push monitors vs Cronitor heartbeats

| Feature             | Logdash                                      | Cronitor                                                        |
| ------------------- | -------------------------------------------- | --------------------------------------------------------------- |
| Expected interval   | Fixed 15-second window                       | A schedule you set, such as every 5 minutes, plus grace seconds |
| Plan                | Pro only                                     | 5 monitors on the free plan                                     |
| A run that fails    | Reported when the next window comes up empty | Reported at once with a ?state=fail ping                        |
| Free alert channels | Telegram and webhook                         | Email and Slack                                                 |

### When Cronitor is the better pick

- The job runs on a schedule. Cronitor knows it and alerts after the grace period; Logdash would alert between runs.
- You are not on Pro. Cronitor watches 5 jobs for free.
- You want a crashed run reported the moment it crashes, not one window later.

## Set one up

1. **Create a push monitor** Push monitors are on the Pro plan. Add a service in Logdash, switch its monitor to push, and copy the id from the ping URL.
2. **Ping after the work** Export LOGDASH\_MONITOR\_ID, start the worker above, and the monitor goes green within one 15-second window.
3. **Kill the worker** Stop the process. The next window comes up empty, the monitor flips to down, and a Telegram message lands on your phone naming the monitor and saying no call arrived. Start the worker again and a second message says it is back up.

### What is heartbeat monitoring software? 

A service that hands you one URL per job, records every call to it, and alerts you when the calls stop. Healthchecks.io, Cronitor and the push monitor type in Uptime Kuma all work this way. Logdash push monitors do too, with a fixed 15-second window, so they suit always-on workers rather than scheduled jobs.

### How does heartbeat monitoring work with cron? 

Add a curl after && on the crontab line, so the ping only fires when the command exits 0\. The monitor then has to know the schedule plus a grace period, or it alerts between runs. Healthchecks.io takes a cron expression with a timezone and a grace time. Logdash has no schedule setting, so for cron use an HTTP check on when the job last succeeded.

### What is a heartbeat check? 

One window in which the monitor expects a call. A call inside it means the process is alive and finished a pass. An empty window means it stopped, and that is when the alert goes out. In Logdash on Pro, one window is 15 seconds.

### What is heartbeat monitoring compared to uptime monitoring? 

Uptime monitoring pulls: the monitor requests your URL and judges the answer. Heartbeat monitoring is push: your process calls the monitor and the monitor judges the silence. Use uptime checks for anything with a URL and heartbeats for anything without one.

## Keep reading

[All uptime monitoring explainers](https://logdash.io/learn): Fourteen uptime questions, each answered in one sentence, then the math or the command behind it.

[What is cron monitoring](https://logdash.io/learn/what-is-cron-monitoring): Cron monitoring tells you when a scheduled job did not run or did not succeed, by having each successful run leave a signal and alerting you when the expected signal is missing.

[How to check if a website is down](https://logdash.io/learn/how-to-check-if-a-website-is-down): Load the site from a second network, such as your phone on mobile data, and run curl against it from a terminal: if both fail it is down for everyone, and if only your connection fails the problem sits between you and the site.

[How to get notified when a website is down](https://logdash.io/learn/how-to-get-notified-when-a-website-is-down): Point an uptime monitor at the URL and connect an alert channel you actually read: the monitor requests the site every few minutes and messages you the moment a check fails, then again when it recovers.

[Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.
