Know the moment a silent job stops running.
Uptime monitoring tells you your site is up. It can’t tell you your nightly backup stopped three weeks ago. Give every cron, job, and backup a unique ping URL — and get alerted the instant an expected heartbeat is missed.
How it works
01
Add a heartbeat asset
Create a heartbeat monitor and Merlonix mints a unique, unguessable ingest URL (POST /v1/heartbeat/<token>). Set the interval you expect a beat and a grace window for jitter.
02
Ping it at the end of your job
Add one line to your cron / backup script / worker — a POST (curl, fetch, anything) to the ingest URL when the job finishes successfully. The token is the only credential; nothing to install.
03
We watch the clock
The scheduler evaluates each heartbeat against its expected period + grace. As long as beats arrive on time, all is well — no news is good news, correctly.
04
A missed beat pages you
When no beat arrives within period + grace, the job is flagged missed and you get an alert — the exact moment your silent job stopped, not the next morning when someone notices the stale data. When beats resume, it recovers.
What to put a heartbeat on
If its silence is a problem, give it a heartbeat.
Anything that should run on a cadence and has no endpoint to probe is a candidate — the failures that otherwise surface days later as stale data or a missing backup.
Why a dead-man’s-switch matters
Catch the failure uptime monitoring can’t see
An HTTP uptime check proves your website answers requests. It says nothing about whether your 2 a.m. backup ran, your billing reconciliation fired, or your data sync completed. Those fail silently and invisibly — a dead-man’s-switch is the only monitor that catches a job that simply never ran.
No agent, no inbound access
Heartbeat monitoring is inbound: your job reaches out to a URL. Merlonix never needs credentials into your infrastructure, a VPN, or an installed agent — which means it works for anything that can make an HTTPS request, including cron on a locked-down box or an IoT device.
One panel with the rest of your monitoring
A missed heartbeat lands in the same alert stream and asset list as your SSL expiry, DNS, security-header, and uptime checks — so a dead cron reaches the same on-call person, the same way, as everything else you watch.
What we promise — and what we don’t
We watch for the beat. You send it.
Heartbeat monitoring is inbound: Merlonix never reaches into your infrastructure — your job POSTs to a unique tokened URL, and we alert when an expected beat is late by more than your grace window. A monitor that has never received a beat stays quiet until you configure it. We tell you, precisely, when a job stopped checking in; keeping the job running is on your side. No fabricated status, no agent to install.
Common questions
What is a heartbeat / dead-man’s-switch monitor?
It is an inbound monitor: instead of Merlonix probing your service, your job pings a unique URL each time it runs successfully. If an expected ping does not arrive within the interval and grace window you set, Merlonix alerts you that the job was missed. It is the standard way to monitor things that have no public endpoint to probe — cron jobs, backups, batch pipelines, and devices.
How is this different from uptime monitoring?
Uptime monitoring makes an outside request to your site and checks that it answers. Heartbeat monitoring waits for your job to check in. A website can be perfectly up while its nightly backup silently stopped weeks ago — uptime monitoring will never tell you, and heartbeat monitoring tells you the first time a beat is late.
How do I send a heartbeat?
Add a single HTTPS POST to the unique ingest URL at the end of your job — for example a curl at the end of a cron line or a fetch at the end of a worker run. The token in the URL is the only credential; there is nothing to install and no agent to run.
When exactly does it alert?
You configure an expected period (how often a beat should arrive) and a grace window (slack for normal jitter). When the time since the last beat exceeds period + grace, the job is flagged as missed and you are alerted. When beats resume, the monitor recovers. A monitor that has never received a beat stays quiet until you have configured it and started pinging.
What can I monitor with it?
Anything that runs on a schedule and can make an HTTPS request when it finishes: nightly and hourly backups, cron jobs, scheduled reports, data pipelines / ETL, queue workers, sync tasks, and connected devices. If it should run on a cadence and its silence is a problem, a heartbeat catches it.
Stop finding out your backup died from the restore that failed.
Give your critical jobs a heartbeat and get paged the moment one goes quiet. Start the full-workspace trial — 14 days, no card.