Know the moment a scheduled job stops checking in
Your cron jobs, backups, and data pipelines ping Checkly when they finish. Miss the window and the right team gets paged. Silence becomes the signal, and every monitor is defined in code.
Ping URL
The heartbeat monitor expects a HTTP request (GET or POST) to the ping URL once per period. Configure your monitored task to ping the URL when successful. See the quickstart section on how to set this up in various languages.
https://ping.checklyhq.com/68dad8a1-623f-48fa-90cf-e4ab87629e47To ping Heartbeat by this link you will first need to save it. Save
Period and Grace
Period is the expected time between pings. Grace is any additional time Checkly will wait before alerting in case the job is late.
The time interval at which your job is scheduled to run.
Accounts for slight delays in job execution.
Trusted by teams that can't afford a job failing quietly
.svg){kind=small}
“Few things in site reliability are as frustrating as having a system go down only to learn that your backup scripts stopped running at some point and you didn't notice. Checkly's heartbeat feature made it extremely simple to monitor my backup process for reliable execution.”
Most monitoring watches for errors. Heartbeats watch for silence
An API check calls your endpoint and waits for a reply. A heartbeat monitor works the other way around: your scheduled job calls Checkly. Tell it how often to expect a ping and how much lateness to tolerate. When the ping does not arrive inside that window, Checkly counts the silence as a failure. A backup that quietly stopped running a month ago becomes a page tonight.
Same job, one week. Late runs stay inside the grace window and never page. The night the ping never lands, the escalation fires once, for the failure that is real.
Period and grace, tuned to reality
Set how often a job should check in, then add grace for the runs that go long. A nightly backup that usually finishes by 2 a.m. can drift to 4 without paging anyone. Only silence past period plus grace counts as a failure.
Ping from anything with a URL
A heartbeat is one HTTP call. Drop a curl at the end of a bash script, add a step to a GitHub Action, fire a request from your app, or attach it to a Kubernetes CronJob. If it can reach a URL, it can check in.
Silence routes to the right people
A missed ping is a real Checkly alert, so it travels the same channels as the rest of your monitoring. Failures to PagerDuty, late runs to Slack, recoveries back to the same channel. Each channel picks the alert types it carries.
Three steps to a monitored job
From no coverage to a paged on-call in a few lines. Create the monitor, ping it from your job, and point it at the channels that should hear when it goes quiet.
Create the monitor
Define the schedule you expect. period sets the interval between pings, grace adds slack for slow runs. Every monitor gets its own ping URL. Keep it in your repo as a TypeScript construct, or click it together in the app.
Ping on success
Add a single HTTP call at the very end of your job, after every step has succeeded. Send a GET or POST to your ping URL. Add an Origin header when you want to see which host checked in.
Route the alert
Attach the channels that should hear about it. When a ping is missed, Checkly opens the alert on the channels you chose and closes it the moment the job checks back in.
Every monitor is a construct in your repo
Prefer the UI? Heartbeat monitors have full parity in the web app, with a Terraform provider too.
“We love Heartbeat Checks! They help us ensure that critical operations run to completion and on time. We had previously evaluated other platforms just for their heartbeat checks, so we are happy to see these within Checkly along with the API and browser checks.”
Stop finding out weeks later
Create a heartbeat monitor, drop one curl at the end of your job, and wire up a channel. The next time a scheduled job goes quiet, you will know that night, not when someone needs the backup.
No credit card required.