every job has a pulse.
silence is the signal.
a silence monitor for cron jobs, workers, backups and sweeps. each job proves it's alive by having a heartbeat. the beets learn your job's rhythm and natural variability. when something is amiss one of the beets pages you. nothing to configure, nothing to install: just HTTP.
how it works
quickstart
grab your API key
heartbeet is free for most use, every user gets 2 projects, unlimited API keys, paging by email, and shareable dashboards. sign in with one click and generate one or more keys for your project.
sign in →POST a distinctive name
paste the call into your cron, worker, build script, or the thing you want to monitor. the path is a name you invent; the first heartbeat creates the job. no registration step: it just shows up, already being watched.
POST /backup-runner HTTP/1.1 Host: heartbeet.page Authorization: <api-key>
your jobs are being watched
the beets learn each job's rhythm as it shows up. stay on schedule and the monitor stays green; go silent and one of the beets pages you. and when you add a job next month: invent a name, paste that line into the PR; that's the whole rollout. nothing to configure, nothing to register, nothing to update.
the whole API
there are two endpoints and some optional query params. no SDK, no AI agent, no registration, just a POST call.
send a heartbeat whenever your job runs successfully by POST'ing to /job-name. you don't have to register the name anywhere, just pick a new name for a new job and it will show up on the dashboard.
before planned quiet time you should POST a pause. for instance add a curl command to the deploy step in your pipeline. the reason you should do this is to avoid the beets getting confused by planned downtime. (you should still pause even if you have rolling, zero-downtime deploys! )
there are tags if you want them. don't use them if you don't care.
send a heartbeat ( | )
# from your job, every run POST /backup-runner HTTP/1.1 Host: heartbeet.page Authorization: <api-key>
announce a planned interruption ( | )
# before a deploy or planned shutdown POST /pause/backup-runner?wait=10m HTTP/1.1 Host: heartbeet.page Authorization: <api-key>
buffer a draining deploy ( | )
# a deploy that keeps sending heartbeats while it runs POST /pause/backup-runner?drain=2m&wait=10m HTTP/1.1 Host: heartbeet.page Authorization: <api-key>
examples of different situations a job can be in
sending heartbeats right on schedule. as long as a job keeps pinging in its own rhythm, all you see is a calm green pulse.
muted. the beets still watch it and record its silences, they just won’t page you. for noisy or low-stakes jobs, test environments or other jobs you don’t want to get paged about.
a real outage. it stayed silent past its deadline, so a beet opened an incident and paged you. the red is the absence of a heartbeat.
a deploy. the pause carries a buffer so the job can stop and restart cleanly. heartbeats during the buffer don’t end the pause early.
a fast job, sending heartbeats every couple of minutes. the beets learn each job’s own rhythm, so "on time" means on time for this job.
a close call. the heartbeat came back later than its usual rhythm but still inside the grace period, so it recovered before anyone was paged. the amber shows how close it got.
paused. someone snoozed paging for a planned quiet spell (maintenance, a long backfill). come back in time and nobody’s paged.
a pause buys time. when it ends, the job gets one normal heartbeat window to recover; still quiet after that, and a beet pages you.
see some examples of real dashboards
real heartbeats from an actual server I run in the cloud, pinging heartbeet all day with jobs I made up. your dashboard would probably look kinda like this, just hopefully with less dramatic events.
a real app I run in production. real heartbeats from real jobs, live right now.
play around with simulating calls like POST /job?tag=prod and POST /pause?tag=prod&wait=10m by creating fake jobs that ping heartbeet from your browser.
watch the dashboard update live. it's a real backend, not a fake demo. (open it in incognito to watch it being driven from your other tab if you don't believe me.)
heartbeet monitoring heartbeet. all the background jobs that drive heartbeet, including the job that opens incidents, are shown here; whether it will be able to detect itself being down is another matter.
tell me all the details!
gladly. the docs cover what the beets actually learn and when they decide to page, the full API, guides for the classic setups (backup scripts, GitHub Actions schedules), and side-by-side comparisons with the other tools in this space.
read the docswill heartbeet be free for my usecase?
yeah probably, heartbeet aims to be as free as possible for as many users as possible. the beets don't work for free though! I gotta pay them and I appreciate everyone who is willing to chip in. you get some benefits to sweeten the deal.
see the pricing page →