Pair external cron with dead-man checks so silent failures are obvious.

The two-schedule pattern is the cleanest. One schedule does the real work (call your /sync, /billing, /import endpoint on a normal cadence). A second schedule fires every 5 to 10 minutes and just hits the Healthchecks ping URL. As long as both keep firing, the dead-man stays green; if either stops, the alert lands in your inbox or chat channel.

One concrete pattern from the dataset: a real Crontap customer running a 6-hourly heartbeat against hc-ping.com/{uuid} next to a longer-running fulfilment job, so the dead-man is independent of the work. When the work job paused after a deploy, the heartbeat caught it within 10 minutes instead of waiting for the daily report run to silently produce nothing.

For tighter coupling on jobs that reliably return 200, you can skip the second schedule and have Crontap's success integration ping Healthchecks after the real run completes. The failure integration can do the same for the failure ping URL. That keeps you to one schedule per job at the cost of one shared failure mode (if Crontap itself goes down, neither the work nor the heartbeat fires; the second-schedule pattern preserves the independence).

Failure surface is the same as every other Crontap schedule: email / webhook (Slack / Discord / Telegram), with the run's status code, duration, and response body in the alert payload.