Some failures never send an error. A process can be killed, a scheduler can stop, or a device can lose power before it reports anything. Cronitor expects the next heartbeat and alerts you when it never arrives.
Attach a metric to each heartbeat — records processed, loop iterations, duration, latency, tokens, or cost — and Cronitor tracks the values over time.
Cronitor checks timing and metric values separately. A job can keep sending beats on schedule while its throughput falls for hours; you can alert on the bad value even though the heartbeat arrived on time.
Uptime checks need something reachable: a hostname, port, or URL. But much of the software you depend on lives behind a private network. A queue worker, nightly script, remote sensor, or agent may have nothing you can request from the outside.
Those systems can still make one outbound HTTPS request when they finish a unit of work. You tell Cronitor how often to expect that heartbeat, and Cronitor watches the time between requests. Nothing needs to be exposed, forwarded, or allow-listed.
This catches failures that leave no error behind. A killed process cannot report its own failure. A stopped scheduler cannot run an error handler. A device without power cannot send a final message. In each case, the missing heartbeat is the signal.
A heartbeat is a single HTTPS request from your code to a URL we hand you. Send it when the work is done. Cronitor records the time, measures the gap against the cadence you declared, and starts a grace period the moment the next one is late.
Cronitor makes the request, on your schedule, from the regions you choose. It needs something reachable, and what it proves is that your endpoint answered correctly.
Your code makes the request, when the work is actually finished. It needs nothing reachable, and what it proves is that the work happened at all.
Most teams run both — a check on the endpoint customers hit, and a heartbeat from the worker behind it.
Heartbeats work for things that do not have an endpoint to check — a mailing list, crawl map, webhook subscription, or fleet of devices you will never SSH into.
Know when an internal host or container stops reporting, without exposing it to an uptime check.
Add Cronitor as a subscriber to any important mailing list and know instantly if email stops flowing.
Send heartbeats on key system and application events and follow trends over time.
Include heartbeats in crawl maps and be alerted if ingestion or scraping activity stops.
Subscribe Cronitor to a webhook and get alerted when a third-party service stops sending events.
Send heartbeats from internet-connected devices and see which ones have stopped reporting.
Every scheduled agent run can emit a heartbeat — know the moment your automations stop.
See every heartbeat monitor and its current status on one live dashboard.
Daily, weekly and monthly reporting for your whole team, so everybody stays informed.
Provision and version-control monitors with YAML and the Cronitor CLI.
Add monitoring to any codebase in minutes with one of our official, open source SDKs.
The worker that sends the beat, the cron job that schedules it, and the endpoint it writes to are three monitors in the same account — one dashboard, one alert pipeline, one status page. When a beat doesn't arrive, the alert goes out the same way it does for a failed check or a late job.
Heartbeat monitoring is a dead man's switch for software: a system you care about sends a simple ping to its unique Cronitor URL on a regular interval, and Cronitor alerts you when the pings stop arriving. It works for anything that can make an outbound HTTP request — jobs, daemons, data pipelines, devices, and AI agents.
A heartbeat is just a GET request to your monitor's unique ping URL, sent with curl, any HTTP client, or one of Cronitor's SDKs. No inbound network access or installed agent is required, so it works from locked-down hosts, containers, and edge devices.
An uptime check is active monitoring: Cronitor probes your endpoint from its global network. A heartbeat is passive: your system reports in to Cronitor. Heartbeats are the right choice when the thing you are monitoring has no reachable endpoint to probe, like a cron job, background worker, or an agent running inside a private network.
Add a Cronitor heartbeat ping to the agent's scheduled execution path. Cronitor expects that independent evidence at the configured interval and alerts you if it stops arriving, even when the agent, its gateway, or its host cannot report its own failure.
A bare ping is enough to prove the agent is alive. The same stateless request can include tokens, actions, and cost metrics so Cronitor can show activity and alert on no-op streaks, unusual token use, or cost spikes.