Heartbeat checks#

An ordinary check is polled: a monitor dials your target on a schedule and reports what it found. A heartbeat is the reverse. Your system calls a URL that Tenpm Uptime gives it, on a schedule, and you’re alerted when the calls stop.

That makes it the right tool when there’s nothing for a monitor to dial:

• A cron job or backup script — call the URL when the job finishes. If the job fails, hangs, or never starts, the call never happens and you’re told.
• An Uptime Kuma (or similar) running on an internal network that can reach out to the internet but can’t be reached from it. Point an HTTP(s) monitor in Kuma at your heartbeat URL; each time Kuma runs it, that’s a heartbeat. If Kuma or its network goes quiet, you hear about it.
• Any system that can make an HTTP request when something happens.

No monitor is involved anywhere. A heartbeat is never assigned to one, and nothing about it is sent to any monitor.

Creating a heartbeat#

Go to Heartbeats in the navigation bar and choose Add heartbeat.

You’re alerted once nothing has arrived for the interval plus the grace period. A 24-hour interval with a 1-hour grace period alerts 25 hours after the last beat.

Your plan’s minimum check interval also applies to a heartbeat’s interval, both when you create it and when you edit it.

Getting the URL#

The list doesn’t show it. Open a heartbeat (URL on its row) and its detail page shows the full Heartbeat URL, with a Copy button and a few ready-made examples.

The URL contains a secret token, and anyone who has it can report for that heartbeat. Treat it like a password. Every member of your organisation can see it on the detail page.

If it leaks, or you just want to rotate it, use Generate a new URL on the detail page. The old URL stops working immediately, so update whatever calls it.

Calling it#

Send a GET or a POST to the URL. That’s all — no body, no headers, no authentication beyond the token in the path.

From a cron job or script:

your-command && curl -fsS -m 10 --retry 3 https://tenpmuptime.com/heartbeat/<token>

The && is the important part. The call only happens when the job succeeds, so a job that fails goes quiet — and quiet is what triggers the alert.

From Uptime Kuma: add an HTTP(s) monitor with the heartbeat URL, method GET, and an interval no longer than the interval you set on the heartbeat. (This is Kuma’s ordinary HTTP monitor calling us — not its “Push” monitor type, which points the other way.)

Reporting a failure explicitly: add ?status=down to the URL to alert immediately instead of waiting for silence. The next call without it (or with ?status=up) marks the heartbeat recovered.

# the backup script noticed it failed - say so now
curl -fsS "https://tenpmuptime.com/heartbeat/<token>?status=down"

status accepts only up or down. Any other value is rejected with a 400 on purpose, so a typo like status=dwon can’t quietly read as healthy. Every other query parameter — including the msg and ping that Kuma’s push convention adds — is ignored, and nothing a sender supplies is stored or shown in an alert.

What the URL answers#

States#

Each heartbeat shows one of these badges:

• waiting for first heartbeat — created, but nothing has arrived yet. It never alerts in this state: a heartbeat you’ve just made hasn’t missed anything.
• up — the last call arrived within the interval plus grace.
• down — nothing arrived in time (or a call said status=down). You’ve been notified. It returns to up on the next ordinary call, and you get a RECOVERED notification.
• paused — you unticked Enabled.
• disabled by platform — a platform administrator switched it off. Your own Enabled setting doesn’t override this.

The detail page also shows when the last heartbeat arrived, the deadline it will alert at, which channels are notified, and a Down history of every outage with how long it lasted.

Alerts read HEARTBEAT DOWN: <name>, HEARTBEAT STILL DOWN: <name> (the repeat, if you set Resend while down) and HEARTBEAT RECOVERED: <name>. They also appear on the Notifications page.

Two details worth knowing#

• The recorded outage starts when the beat was missed, not after grace. Grace is a tolerance before alerting, not part of the outage, so Down history can show an outage that began earlier than the moment you were actually notified.
• Changing the interval or grace period doesn’t reset anything. Shorten the interval and a heartbeat that was healthy can become overdue at once — it really has been silent for longer than it’s now expected to be.

Pausing a heartbeat#

Untick Enabled while you take the sender down for maintenance. A paused heartbeat refuses calls and can’t alert, and any outage in progress is closed without a recovery notification. When you enable it again, the deadline clock restarts, giving the sender a full interval plus grace to resume — so a heartbeat paused for a week doesn’t page you the moment you switch it back on.

Plans and limits#

How many heartbeats you can have depends on your plan:

Heartbeats are a separate budget from your check count — they neither use up nor draw from it. See Plans and billing for the rest of what each plan includes.

Two rules:

• 0 means none, not unlimited. A plan (or a custom deal) with a heartbeat limit of 0 doesn’t include the feature at all.
• The limit is only checked when you create one. If you downgrade below the number you already have, they keep working — you just can’t add another until you’re back under the limit.

Not on the status page#

Heartbeats don’t appear on your public status page, only checks do.