Docs

Heartbeat monitors

Heartbeat monitors are push based, the inverse of every other monitor realuptime has. Instead of realuptime reaching out to check on something, your job checks in with realuptime, on its own schedule.

What it is

A heartbeat monitor watches a cron job, backup script, queue worker, or any other process that runs on its own schedule rather than serving requests. Your job requests a unique realuptime URL each time it runs. If those pings stop arriving for longer than the monitor's configured interval plus its grace period, the monitor is marked down and the normal alert fan-out fires, the same incidents, Slack, email, PagerDuty, and webhook channels every other monitor on realuptime uses. Recovery is simply the next ping arriving.

No probe regions are involved in either direction. Unlike an HTTP monitor, realuptime never reaches out to your infrastructure for a heartbeat; it only listens for the ping you send it.

The ping contract

Send a GET or POST request to https://realuptime.io/api/ping/<token>. Both verbs are accepted, since the caller is typically curl, wget, or a scheduler's "call a webhook" step, and forcing a particular verb on a crontab line is a pointless integration failure.

The token is generated once when the monitor is created, or re-generated from the dashboard, which invalidates the old one. The token is the credential: treat the ping URL as a secret, the same way you would treat an API key.

A successful ping returns a tiny 200 plain-text body and nothing else, no JSON, no customer data. An unknown or malformed token returns a bare 404, deliberately indistinguishable from each other, so the endpoint can never be used to confirm whether a guessed token exists.

Pings are rate limited to 120 requests per minute per token, generous headroom for retries and clock skew on a correctly configured job, while still stopping a tight-loop misconfiguration from becoming unbounded traffic.

Arming

A heartbeat that has never received a ping is awaiting first ping, not down. Monitoring only arms on the very first ping the token receives, matching how other tools in this space behave. A monitor you just created but have not wired up yet will never page anyone.

Interval and grace period

Heartbeats share the same 60 second floor and 24 hour ceiling as every other monitor type on realuptime, set at monitor creation. The grace period is extra slack past the interval before a late ping counts as down, useful for a job whose runtime varies, so a normal few extra seconds or minutes doesn't trigger a false alert.

Setup

Create a heartbeat monitor from the dashboard's Add monitor flow, choosing Heartbeat, then copy the ping URL it gives you. A simple manual check:

curl https://realuptime.io/api/ping/YOUR_PING_TOKEN

The usual case is a crontab entry that pings after the job runs, discarding the response:

*/5 * * * * curl -fsS https://realuptime.io/api/ping/YOUR_PING_TOKEN > /dev/null 2>&1

If you lose or need to rotate the token, regenerate it from the monitor's own detail page. Regenerating invalidates the old URL immediately.

Availability and pricing

Heartbeat monitors are available on every plan, free included, and count against the same monitor-slot limit as HTTP monitors. There is no separate heartbeat allowance and no extra cost. See pricing for what each plan includes.