The worst cron failure often has no error message. The machine restarted, the platform skipped a trigger, or somebody disabled the schedule during a deploy. The job never begins, so its error handler has nothing to report.
Until now, our recommended answer was to pair Crontap with an independent heartbeat service. That is still a sound pattern when the scheduler and alerter must live in different systems. Most teams, though, wanted the simpler version in the dashboard they already use.
Today we are shipping Crontap Heartbeats. Give a recurring job a secret ping URL, call it after a successful run, and Crontap alerts when the expected ping does not arrive.
What ships today
The first release covers the heartbeat loop from setup through recovery:
- Period + grace: choose how often a ping should arrive, then allow the amount of lateness that is normal for the job. Periods range from 1 minute to 31 days.
- Explicit failure: append
/failto report a known failure immediately. Add a short message to make the alert useful. - Email + webhook alerts: missed, failed, and recovered events go to email and an optional generic JSON webhook.
- 90-day history and reliability: the percentage measures real successful outcomes against successes, failures, and misses. UI test pings do not affect it, while daily colors continue to show incident severity.
- Secret URL rotation: replace a leaked token without recreating the heartbeat or throwing away its history.
- Public API: create, read, update, rotate, and delete heartbeats through the same authenticated API surface as the rest of Crontap.
A heartbeat becomes late after its period ends. It becomes down after the grace deadline, and the detector finds that state within one minute. The notification cron then sends queued email and webhook alerts on its next run. That last detail matters: the one-minute promise covers detection after grace, not notification delivery.
See the complete feature at crontap.com/heartbeats.
A 60-second setup
Create a heartbeat, copy its URL, and wrap the existing job. This is the same crontab pattern shown in the product:
# /path/to/job-with-heartbeat.sh
/path/to/job.sh
status=$?
ping_url="https://ping.crontap.com/YOUR-TOKEN"
[ "$status" -eq 0 ] || ping_url="$ping_url/fail"
curl -fsS -m 10 --retry 3 "$ping_url" > /dev/null
exit "$status"
# crontab: */5 * * * * /path/to/job-with-heartbeat.shCapturing $? before the ping is important. The wrapper should report the job's result, then exit with that same result. A successful curl must not turn a failed backup into a green run.
The setup page also includes ready-to-copy examples for GitHub Actions, Node.js, Python, Docker and Kubernetes CronJobs, Windows Task Scheduler, WordPress wp-cron, and Crontap schedule integrations.
How Heartbeats fits with Schedules and Uptime
These features watch different directions:
- Schedules mean Crontap owns the clock and calls your URL.
- Uptime means Crontap probes a URL to check whether it responds.
- Heartbeats mean your job runs anywhere and calls Crontap to prove it completed.
A public API can be up while its nightly import stopped three days ago. An import can complete every night while the public API is down. Monitoring both signals gives you a much more useful answer than asking either one to stand in for the other.
Most teams use two of the three. The heartbeat vs uptime guide has the longer decision framework.
Pricing
Heartbeats use the same combined cap as schedules and uptime monitors. There is no heartbeat add-on:
- Starter includes 1 heartbeat at hourly cadence or slower, sharing the plan's 2 combined items.
- Pro starts at $2.99 per month for 3 combined items and unlocks heartbeat periods down to 1 minute.
- Larger Pro and Ultra caps use the same slider on the pricing page.
What is not in v1
We kept the first release focused on the signal every recurring job can send. These are not in v1:
- Start and duration signals. Crontap records success, explicit failure, missed deadlines, and recovery, but it does not yet model a separate job start or calculate run duration.
- Cron-expression expectations. A heartbeat expects an interval plus grace, not “weekdays at 09:00 Europe/Berlin.”
- Direct Slack delivery and native formatting. Email and generic JSON webhooks ship now, but that payload is not a valid Slack incoming-webhook message by itself. Use Zapier, Make, or your own relay endpoint until dedicated Slack formatting and routing controls arrive.
If one of those changes whether you can adopt Heartbeats, tell us what you need. Concrete job shapes are more useful than feature votes.
Migrating from Healthchecks.io
For many teams, moving a straightforward check takes three steps:
- Create a Crontap heartbeat with the same expected period.
- Replace the existing ping URL in the job with the new Crontap URL.
- Start with grace around 20% of the period, then adjust it to match real run variation.
Run both watchers in parallel before deleting the old check. Keep Healthchecks.io, Cronitor, or another independent watcher when your risk model requires the scheduler and alerter to fail independently. Our Healthchecks.io comparison is explicit about when that separation is worth keeping.
The feature is live now. Create a free heartbeat, add one outbound request to a job, and turn the next silent miss into an alert you can act on.