A cron job that fails can say so: the cron guide sends a push when a job exits with an error. A job that never runs can’t. The crontab line got lost when you moved servers, the machine is off, the cron daemon stopped, or the job hangs and never finishes. Nothing fails, so nothing is sent, and you find out on the day you need last night’s backup.

A heartbeat turns this around, which is why it’s also called a dead man’s switch. The job calls a URL every time it runs. Honk knows how often to expect that call, and when it doesn’t come, Honk opens a problem and pushes to your iPhone, Apple Watch or browser. The next call closes it.

How a heartbeat works

You set an interval: how often a check-in should arrive, from 1 minute to 1 week.
And a grace period: how much later it may arrive before Honk calls it late, 5 minutes by default. The deadline is the last check-in plus the interval plus the grace period.
Each heartbeat has a secret URL, https://honk-honk.app/hb/…. A GET, POST or HEAD request to it is a check-in, with no key or header.
When the deadline passes, Honk opens a problem in the project, a Long honk unless you choose another level. It reads “Nightly backup is late” with “No check-in since 2026-10-14 03:12 UTC. Expected every 1 d (+5 min grace).” Honk checks at least once a minute.
One outage, one problem. While the job stays silent, Honk adds nothing: no new push every minute.
The next check-in closes it with a recovery, “Nightly backup is back,” which is pushed like any other.

The problem is an ordinary Honk event in the group heartbeat/<slug>, so quiet hours, mutes, Live Activities and your rules treat it like everything else. A new heartbeat waits for its first check-in, and it can’t be late before that.

Before you start

A Honk account and a project. Honk is invite-only for now; request access if you don’t have one.
Permission to manage the project. Workspace owners and admins have it.
Room for one more heartbeat: a workspace can have 2 on the Free plan, 20 on Pro and 100 on Team (plans).
curl on the machine that runs the job. It’s on almost every server.

1. Create the heartbeat

In the web app, open the project, then Connections, and choose New heartbeat:

Name: what the push will say, such as “Nightly backup.”
Expect a check-in every: 5 minutes, 15 minutes, 1 hour, 1 day, 1 week, or a custom number of minutes.
Grace period: none, 1, 5 or 15 minutes, or 1 hour.
Level when late: a Long honk by default, or a Blast for the jobs that matter most.

Save it, then open Set up and copy the Check-in URL. Anyone who has the URL can check in, so keep it like a password. If it leaks, New URL replaces it, and the old one stops working at once.

2. Check in after each run

Add the call after the job with &&, so that only a successful run checks in:

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

-fsS keeps curl quiet unless something goes wrong, -m 10 gives up after 10 seconds, and --retry 3 rides out a short network problem. When the job fails, there’s no check-in, and Honk pushes once the grace period runs out.

The deadline counts from the last check-in, so the grace period only has to cover how much the job’s timing varies. If the backup sometimes takes 20 minutes longer than usual, give it at least that much.

3. Report a failure right away

Waiting for the deadline is fine for a nightly job. To hear about a failure the moment it happens, call the URL with /fail when the job fails. Text you send in the body, up to 1 KiB, becomes the message:

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null || curl -fsS -m 10 --retry 3 --data-raw "pg_dump failed on $(hostname)" https://honk-honk.app/hb/…/fail > /dev/null

Honk opens the problem at once: “Nightly backup reported a failure.” The next successful check-in closes it, as before.

If the job already reports its failures with the honk-cron wrapper from the cron guide, keep that, and let the heartbeat watch only whether the job runs. Check in after every run, failed or not, with ; instead of &&:

0 3 * * * /usr/local/bin/honk-cron db/backup pg_dump -f /backup/app.sql app; curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

The wrapper tells you the job failed, with its output. The heartbeat tells you it didn’t run at all.

Workers, apps and systemd

Anything that can make an HTTP request can check in: a queue worker after each batch, a script in any language, or a systemd service. The Set up panel in the web app has ready-made lines for crontab and for systemd’s OnSuccess= and OnFailure=. Honk counts at most one check-in every 10 seconds; extra calls are answered and ignored.

Code that already has an ingestion key can use the API instead of the URL. The heartbeat is created on its first check-in, so a worker can set up its own:

curl -fsS -m 10 --retry 3 https://honk-honk.app/v1/heartbeats/check-in \
  -H "Authorization: Bearer $HONK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"slug":"queue-worker","name":"Queue worker","interval_seconds":300,"grace_seconds":60}'

The slug names the heartbeat within the key’s project. Later calls can change its name, interval and grace period, while the level and pausing stay in the web app. To report a failure, send "status":"fail" with a message.

Weekends, maintenance and pauses

Honk expects a check-in at a fixed interval and doesn’t read cron expressions. For a job that runs only on weekdays, either set the interval to the longest gap (3 days, from Friday to Monday), or add a crontab line that checks in on Saturdays and Sundays.

Before maintenance, Pause the heartbeat. A paused heartbeat isn’t watched, and pausing closes a problem that’s open. Resume starts the clock again from that moment. Deleting a heartbeat also closes its open problem.

Heartbeats and failure alerts

They answer two different questions, and a job that matters deserves both:

The cron guide tells you the job ran and failed, with its exit code and output.
A heartbeat tells you the job didn’t run, or never finished, and when it last checked in.

If you’ve used Healthchecks.io

It’s the same idea: a URL per job, a period and a grace time. Healthchecks.io can also follow cron expressions and systemd OnCalendar= schedules, and it’s open source, so you can run it yourself. Honk has no cron expressions and no self-hosted version. What it adds is that a silent job lands in the same inbox, with the same push rules, as everything else you run: one push per outage, a recovery when the job is back, quiet hours, Live Activities and your Apple Watch.

Honk is invite-only for now: request access. Everything in this guide works on the Free plan.