Topics:Monitoring

Use case

Know when a scheduled job stops running, not just when it fails.

A failed job can log an error. A job that never starts has nothing to log. Crontap Heartbeats gives that recurring job a secret ping URL, then turns silence or an explicit /fail ping into an alert.

Get started

Free plan · no credit card required

The problem

Why this is painful without the right tool

  • A cron stopped firing two weeks ago and nobody noticed until a customer did.
  • The host restarted before the worker began, so the job's error handler never ran.
  • A slow but healthy backup sometimes finishes late and should not page the team.
  • The scheduler reports success when it starts the process, not when the work completes.

The fix

How Crontap solves it

Create a native Crontap Heartbeat with the period and grace your job needs. Ping its secret URL after success, or append /fail with a short message when the job knows it failed. Crontap records the event and alerts connected Notification channels. Generic machine webhooks remain available as Integrations.

crontab wrapper
/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"
Capture the job result before curl, report it, then preserve the original exit status.

1. Let the job ping its own heartbeat. This is the direct dead-man pattern. It works for system cron, GitHub Actions, Kubernetes CronJobs, WordPress wp-cron, and private workers because it only needs outbound HTTPS.

2. Connect a Crontap schedule to a heartbeat. When Crontap starts the work, configure its success integration to ping the heartbeat and its failure integration to call /fail. Schedules own the clock; Heartbeats keep a separate outcome timeline.

3. Keep an independent watcher for stricter risk models. If the scheduler and alerter must fail independently, keep Healthchecks.io, Cronitor, or another external watcher alongside Crontap. That separation costs another system, but it removes one shared failure domain.

For a public URL that should respond all day, use Crontap Uptime. Uptime asks whether the URL responds. A heartbeat asks whether the job checked in.

FAQ

Common questions

Does the job need a public inbound endpoint?
No. The job makes an outbound HTTPS request to its secret ping URL, so it can run behind a firewall or on a private network.
How does grace prevent noisy alerts?
The heartbeat becomes late after its expected period, but no alert is sent until the grace deadline also passes. Misses are detected within one minute after that deadline.
Can the job report a known failure?
Yes. Send the heartbeat to /fail and include a short message. Crontap records a failed event and alerts its connected Notification channels.
Should I keep an independent heartbeat service?
Keep one when the scheduler and alerter must live in different systems. For most teams, native Crontap Heartbeats covers period, grace, /fail, connected alert channels, webhook Integrations, and 90-day history in one dashboard.

Ready to fix it?

Point Crontap at any URL. Pick any cron. Done.

WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.

Free forever tier ・ No credit card required

GET

/wp-cron.php?doing_wp_cron=1

Running
Your next schedule

Schedule

"every 5 minutes"

Next

in 23s