Heartbeat Monitoring
The nightly backup that quietly stopped running is the outage nobody sees. Let every job report itself and hear about the run that never happened.
The check that runs inside your infrastructure
Every other check we run asks a question from the outside: is the port open, does the page answer, is the record still there. A cron job answers none of them — it runs on a machine nobody can reach, it produces no endpoint, and when it silently stops the only symptom is a backup nobody took or an invoice nobody sent. A heartbeat turns that around. Pulsitor gives the job a private token, the job sends it in a header to one fixed address at the end of every successful run, and we watch the clock. Miss the window and the incident opens on its own, through the same channels as every other check.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 -H "X-Heartbeat-Token: YOUR-TOKEN" https://external-services.pulsitor.com/heartbeat/ping
Chained after the command, so a failing backup never reports success.
How a heartbeat check works
What makes Pulsitor powerful out of the box.
The job reports itself
Add one line to the end of your cron entry, worker or deploy script. A GET, POST or HEAD request carrying the monitor token in a header is all it takes — no agent, no library, nothing to install.
You set the period and the slack
Say how often the job is supposed to report — anything from a minute to a week — and how late it may be before it counts as missed. A backup that usually takes twenty minutes gets twenty minutes of grace.
Silence opens the incident
When the window closes without a ping, the incident starts at the moment the report was due, not when we noticed. It closes itself the moment the job reports again.
What people watch with it
Anything that is supposed to run on a schedule and has no address of its own.
Cron jobs
Nightly backups, invoice runs, imports, cache warmers. The classic case: a crontab line that stopped working when the server was rebuilt and nobody noticed for a month.
Queue workers
A worker that died leaves the queue growing quietly behind it. A heartbeat from the end of each batch tells you it is still consuming, not just still listed as running.
Backups and exports
Report only when the dump finished and the upload was confirmed. A backup that reports before it succeeds is worse than no monitoring at all.
Devices and agents
IoT devices, edge boxes and scripts behind NAT that nothing on the internet can reach. They cannot be pinged from outside, but they can call out.
One line in the job you already have
One request is the whole integration: your token in a header, sent at the end of the run once the work actually succeeded.
Crontab
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 -H "X-Heartbeat-Token: YOUR-TOKEN" https://external-services.pulsitor.com/heartbeat/ping
Chained after the command, so a failing backup never reports success.
Shell script
#!/bin/sh set -e pg_dump mydb | gzip > /backups/mydb.sql.gz aws s3 cp /backups/mydb.sql.gz s3://backups/ curl -fsS -m 10 --retry 3 -H "X-Heartbeat-Token: YOUR-TOKEN" https://external-services.pulsitor.com/heartbeat/ping
A short timeout and a couple of retries keep a slow network from opening a false incident.
Application code
Http::withHeaders(['X-Heartbeat-Token' => $token])
->timeout(10)
->retry(3, 200)
->get('https://external-services.pulsitor.com/heartbeat/ping');
Any HTTP client will do. Nothing is read from the response but its arrival.
Why watch a job this way
Catches the silent failure
A job that never starts throws no error and writes no log. Absence is the only signal, and it is the one thing a heartbeat is built to notice.
Reaches where probes cannot
Behind a firewall, on a laptop, inside a private network, on a device with no public address. If it can make an outbound request, it can be monitored.
Same incidents, same channels
A missed heartbeat is an incident like any other: the same alerting channels, the same history, the same status pages your customers already read.
Heartbeat monitoring at a glance
What the check actually does, in numbers.
| Property | Value |
|---|---|
| What is checked | That a request from your job arrives within the expected window |
| Accepted methods | GET, POST, HEAD |
| How the monitor is identified | Token in the X-Heartbeat-Token header, or as Authorization: Bearer |
| Expected period | 1 minute to 7 days |
| Grace period | 30 seconds to 24 hours |
| Before an incident opens | One expected window closed without a ping |
| Notification channels | 14 |
| Available on | Paid plans, from 6 EUR per month |
Heartbeat monitoring questions
What a heartbeat can and cannot tell you.
What exactly is a heartbeat monitor?
A monitor with no target. Instead of us calling your service, your job calls one address of ours every time it runs, carrying its own token in a header. The check passes when the request arrives in time and fails when it does not.
When should the job send the ping?
At the very end, after the work succeeded. Calling it at the start would report a run that may still fail halfway through, which is exactly the outage you are trying to catch.
What is the grace period for?
Real jobs drift. The grace period is how late a report may be before the monitor gives up on it, so a backup that occasionally runs ten minutes long does not wake anybody at night.
Why is the token in a header and not in the URL?
Because a secret in an address does not stay secret: it is written to access logs, to every proxy along the way, to shell history and to the process list of the machine running the job. In a header it stays out of all of them, and every monitor calls the same address.
Can I monitor a job behind a firewall?
Yes, and that is the point. Nothing has to reach your machine — the job only needs to be able to make an outbound HTTPS request.
What happens when the job starts reporting again?
The incident resolves itself on the next ping and the resolution notification goes out on the same channels that carried the alert.
Is heartbeat monitoring available on the free plan?
No. Heartbeat monitors are part of the paid plans, alongside DNS, SSL and domain expiration checks.
Watching a job in 3 steps
Create a heartbeat monitor, name it after the job and say how often it should report.
Copy the token into the job and send it in the header at the end of every successful run.
Pick the channels to be told on and let the schedule watch the clock for you.