Updated 2026-09-29
A heartbeat check flips the usual monitoring model around: instead of Status reaching out to your target, your job reaches in. It's the right check type for cron jobs, scheduled scripts, and background workers that don't expose anything to monitor from the outside.
How it works
Each heartbeat check gets a unique inbound URL. Your job calls that URL
(GET or POST) every time it runs successfully. As long as check-ins keep
arriving inside the configured grace period, the check stays up. If a
check-in doesn't arrive before the grace period elapses, Status raises an
incident — the same way it would for any other check going down.
The URL looks like https://<Status host>/api/hb/<token>; copy it from the
check's page. It always answers 204 No Content, whether or not the token is
valid. You can rotate the token from the check page if it leaks; the old URL
stops working.
Configuration options
- Grace period — how long to wait for the next check-in before considering the job overdue. Set this a bit longer than your job's normal interval to leave room for a slightly late run without notifying you. It can be from 30 seconds to 7 days (5 minutes by default). Heartbeat checks have no interval of their own: the grace period is the deadline.
When to use it
- A nightly backup script.
- A queue worker or sweep job that should always be running.
- Any process where "it didn't run" is itself the failure you want to know about — no probe or URL for Status to poll, just your own job checking in.
A heartbeat check counts toward your plan's check limit like any other check type, but doesn't use probe regions or confirmation, since there's no external target to re-check.