Health Check Ping: The Mechanics of Push-Based Job

What Is a Health Check Ping?

A health check ping is an HTTP request that a scheduled job sends out to a monitoring endpoint to prove it executed. This inverts how most people think about "health checks." A traditional health check is pulled: a monitor hits your /health endpoint every 30 seconds and asks "are you up?" A health check ping flips the direction — the job pushes a signal saying "I ran, and here's how it went." Nobody polls anything; the job calls home.

This matters because the two patterns catch different failures. A polled /health endpoint tells you whether a running service is responsive. It can't tell you that your nightly billing script never started because the cron daemon was misconfigured, the container never scheduled, or a deploy silently disabled the timer. A health check ping catches exactly that case: if the job doesn't run, no ping arrives, and silence itself becomes the alert. This is the same principle behind a dead man's switch — absence of a signal is the signal.

The Anatomy of a Ping Request

Mechanically, a health check ping is almost boringly simple, which is the point. Each job gets a unique ping URL — usually a random token embedded in the path, like https://cronevra.com/ping/8f3a-.... The uniqueness matters: one URL per job means the monitoring system knows exactly which job is reporting in, without extra metadata.

There are typically three call types tied to that one URL:

• Start — fired the moment the job begins, useful for tracking runtime and catching hangs.
• Success (OK) — fired when the job completes without error.
• Fail — fired when the job exits with an error, often as a suffix like /fail on the same URL.

A minimal ping is nothing more than a GET or POST with no body required — the response confirms receipt and updates the job's last-seen timestamp. Here's what it looks like wired into a crontab line:

0 * * * * /usr/local/bin/backup.sh && curl -fsS -m 10 https://cronevra.com/ping/8f3a-xxxx

That single line runs backup.sh, and only if it exits successfully does the curl fire. No success ping, no confirmation — exactly the behavior you want.

Push Ping vs. Pulled Health Check: Why the Direction Matters

The direction of the request is the entire distinction. A pull-based health check assumes something is always listening and asks it to respond; a push-based ping assumes nothing is listening until the job proactively reports in. Only the push model catches a job that never ran at all — a cron entry that was deleted, a container that failed to schedule, a systemd timer disabled after a deploy. A polling monitor has nothing to poll in that scenario, so it stays silent right alongside your broken job. For the deeper comparison of pull-based monitoring and its false-positive pitfalls, see How to Monitor Uptime of a Website (Without False Positives) — a related but separate problem from job-level ping monitoring.

How to Attach a Ping to a Job You Already Run

Retrofitting an existing script takes one conditional, not a rewrite: run the command, check its exit code, then ping success or fail accordingly.

#!/usr/bin/env bash
PING_URL="https://cronevra.com/ping/8f3a-xxxx"

curl -fsS -m 5 --retry 2 "$PING_URL/start"

/usr/local/bin/run_report.sh
EXIT_CODE=$?

if [ $EXIT_CODE -eq 0 ]; then
  curl -fsS -m 5 --retry 2 "$PING_URL"
else
  curl -fsS -m 5 --retry 2 "$PING_URL/fail"
fi

exit $EXIT_CODE

A few details do the real work. The -m 5 timeout caps how long the ping call can block — without it, a hung network request could stall the job that's supposed to be reporting success. The --retry 2 flag absorbs a transient DNS blip or dropped connection so one flaky network moment doesn't erase your signal. And the exit-code branching is what makes fail pings possible at all; without it, you're always pinging success regardless of what happened.

For jobs with meaningful runtime, the start ping matters as much as success or fail — it lets the monitor flag a job that's still "running" long after it should have finished, rather than waiting for a ping that will never come. Set the job's expected check-in window to roughly match its normal runtime plus a reasonable buffer, ideally derived from its cron expression — if you're unsure how those fields map to timing, What Is a Cron Expression? Syntax, Fields & Examples breaks that down. And remember: logs alone won't tell you any of this happened on schedule — see Cron Job Logs: Where to Find Them and What They Miss for why the log file and the ping serve different purposes.

Mistakes That Make Ping Monitoring Useless

Most broken ping setups aren't broken because the concept failed — they're broken because of a handful of implementation shortcuts:

• Pinging unconditionally. If the ping fires regardless of exit code, a crashed job still reports "success." This is the single most common way teams end up with silent cron failures despite having a ping in place.
• No timeout on the ping call. A hanging curl with no -m flag can block the job itself, turning a monitoring safeguard into a new point of failure.
• One shared URL across unrelated jobs. If three different cron jobs ping the same URL, a failure in one gets masked by a success from another arriving moments later.
• Skipping the start ping. Without it, a job that hangs indefinitely never triggers an alert — it just never checks in, which looks identical to "hasn't started yet" until someone notices.
• Hardcoded URLs with no secrets handling. A ping token committed to source control or copy-pasted across environments makes rotation and auditing painful, and can leak into logs.

These are pitfalls, not conceptual flaws — every one is fixable with a few extra lines of shell script and a monitoring layer that actually tracks history.

Frequently Asked Questions

What's the difference between a health check ping and a regular health check endpoint?

A health check ping is push-based: the job sends the request to prove it ran. A regular health check endpoint is pull-based: a monitor polls it to see if a service is currently responsive. Only the ping pattern detects a job that never started at all, since a poll has nothing to check if the job never scheduled.

Do I need to ping on both success and failure, or just one?

Ping on both whenever possible. A success-only setup can't distinguish "job failed" from "job never ran," while a success/fail pair — plus an optional start ping — gives you the full lifecycle and lets alerting distinguish real failures from missed runs.

What happens if my server can't reach the internet to send the ping?

The ping simply never arrives, and a properly configured monitor treats that as a missed check-in and alerts accordingly. This is why retry and timeout flags on the curl call matter — they reduce the chance a transient network issue looks identical to a real outage.

Can I use a health check ping for jobs that don't run on a fixed schedule?

Yes — most monitoring tools support a "cron-less" or manual mode where you just expect a ping within a rolling time window rather than at fixed intervals. This suits event-triggered jobs, queue workers, or scripts kicked off by external systems.

Is a health check ping the same thing as a heartbeat monitor?

They're the same underlying mechanism. "Heartbeat" and "dead man's switch" are older terms for the same push-based, silence-is-the-alert pattern that health check pings implement for scheduled jobs specifically.

What should I do if a scheduled job crashes before it reaches the ping call?

Wrap the entire job in a script that always reaches a ping call, using a trap or a top-level try/catch so even an early crash still triggers a fail ping. If the process is killed outright (OOM, SIGKILL), no ping will fire either way, and a missing start ping combined with a configured grace period is what catches that.

Sending the ping is the easy part — a single curl call. The harder half is everything downstream: keeping execution history, catching partial failures like a fail ping that never gets acted on, applying sensible grace periods, and alerting the right person the moment a check-in goes missing. That's the layer Cronevra — Cron jobs that never fail silently. is built for. Wire up your first ping and see it tracked in minutes, or check the Pricing page if you're ready to move past scripts and spreadsheets for good.