UpCheck

Heartbeat & cron monitoring

Get alerted when a scheduled job stops pinging.

What it watches

Every other check reaches out to your systems. A heartbeat waits for yours to reach in. The monitor gets a ping URL, your job calls it when it finishes, and silence is the failure signal.

That inversion is the point: it's the only way to watch something with no address. A cron job on a box behind a firewall, a nightly backup, a queue worker, a container that wakes up once an hour — none of them have a URL to probe, and all of them can call one.

Interval plus grace, and nothing else to tune

You declare how often the ping should arrive, and a grace buffer for the run that goes long. Miss both and the monitor goes down: the deadline is the last ping plus the interval plus the grace.

Set the grace to your job's worst normal night, not its average one. A backup that usually takes five minutes and sometimes twenty wants a grace that covers twenty, or you'll be woken by a job that was going to finish anyway.

Ping on success, not on start

Put the ping at the end of the job and behind a success condition. && in a shell, if: success() in CI. A job that pings when it starts is a job that reports healthy while it crashes.

A new heartbeat sits waiting until its first ping arrives, so wire the call in right after you create it. Until then there's nothing to be late.

Call the URL when the job finishes

Any method works, GET or POST, and there's no auth and no body. The URL is the whole secret, so treat it like one.

# Only pings when the script exits 0.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 \
https://upcheck-api-a.rekwiem.com/v1/heartbeats/<id>/ping

Tune it when the defaults aren't right

Check interval1m5m10m30m1h
Slow threshold0.5s1s1.5s3s
Request timeout5s10s30s60s
Failure threshold12345
Follow redirectsOnOff
SSL and domain expiryOnOff

Highlighted is the default.

Build trust with
public status pages.

Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.

Explore status pages

Every outage,
written down as it happens.

A failed check opens an incident on its own, and it keeps a timeline: when it broke, what we saw, when it recovered. Nobody has to remember to write the post-mortem's first half.

Explore incidents

Planned downtime
shouldn't page anyone.

Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.

Explore maintenance

Everything else you can watch

Read more

Heartbeat questions

When the last ping plus the interval plus the grace passes with no new ping. Before the first ping ever arrives, that clock runs from when you created the monitor.

The run that goes long. It defaults to 60 seconds. Set it to your job's worst normal runtime, so a slow night isn't a false alarm.

Either. GET and POST both count, there's no auth and no body, so a plain curl at the end of the job is enough.

No. Ping at the end and only on success — behind && in a shell, or if: success() in CI. A ping at the start reports healthy for a job that then crashes.

Set it up in minutes, never miss an outage again.

Free to start · One-minute checks · iPhone, iPad, and Mac