1. Know which failure mode each monitor type actually catches
An HTTP monitor works by RealUptime reaching out to a URL on a schedule; it is the right tool for anything that serves requests, a website, an API, a health-check endpoint. A cron job, a nightly backup script, or a queue worker serves nothing: there is no URL for a probe to reach out to, and the failure that matters is the job silently not running at all, not a slow response. A heartbeat monitor is push-based, the inverse of every other monitor type: your job requests a unique RealUptime URL every time it runs, and the monitor goes down when those pings stop arriving, not when one fails to respond.
2. Send the ping
A successful run sends a plain GET or POST to https://ingest.realuptime.io/api/ping/<token> and discards the response; both verbs work, since the usual caller is curl, wget, or a scheduler's own "call a webhook" step, and forcing one verb on a crontab line is a pointless integration failure. New heartbeat monitors are issued a ping URL on this ingest host per the REA-473 cutover, which moved ingest traffic (errors, heartbeats, agent metrics) onto its own ingest.realuptime.io host; a heartbeat created before that change keeps its already-issued realuptime.io URL working exactly as before; nothing is rewritten retroactively, and both hosts run the identical handler.
3. Know the failure semantics before you rely on one
A heartbeat that has never received a ping reads as awaiting first ping, not down: monitoring only arms on the very first ping the token receives, so a monitor you created but haven't wired up yet will never page anyone. Once armed, a ping later than the interval plus its grace period marks the check down and fires the same alert fan-out every other monitor uses (incidents, Slack, email, PagerDuty, webhooks); recovery is simply the next ping arriving, nothing to acknowledge or reset by hand. An unknown or malformed token answers a bare 404, deliberately indistinguishable from any other reason, so the endpoint can never be used to confirm whether a guessed token is real. Pings are rate limited to 120 requests per minute per token.
4. Create one from the dashboard
From the dashboard's Add monitor form, set Check type to Heartbeat (cron), name it after the job, and set the expected interval in seconds (the same 60-second floor and 24-hour ceiling every monitor type shares) plus an optional grace period in seconds, extra slack for a job whose runtime varies so a normal few extra minutes doesn't trigger a false alert. Saving reveals the ping URL exactly once: copy it immediately, since like every RealUptime credential it is stored hashed and cannot be shown again. If you lose it or need to rotate it, regenerate the token from the monitor's own detail page; regenerating invalidates the old URL immediately.
5. Wire it into the job and confirm it
Add the ping as the last line of the job, after the work it's timing succeeds, so a failed run never sends a false all-clear: for example, a crontab entry that runs the job and then curls the ping URL, discarding the response. Heartbeat monitors are available on every plan including Free, count against the same monitor-slot limit as HTTP monitors, and cost nothing extra. They are also excluded from uptime percentage figures (on the monitor board and the weekly digest) rather than averaged in, since a push-based check has no meaningful uptime denominator the way a polled check does.
Go deeper
The full reference lives in the docs: Heartbeat monitors documentation. Error codes named above are each explained in the error-code reference.