Healthcheck: What It Means Across Your Whole Stack

What Is a Healthcheck?

A healthcheck is a lightweight, automated check that reports whether a system is up and functioning correctly. Something asks "are you okay?" on a schedule, and the system answers with a simple yes/no signal that a load balancer, monitoring tool, or orchestrator can act on: route traffic, restart a container, or page an on-call engineer.

The confusion around healthcheck meaning isn't that the concept is complicated — it's that the term gets reused across layers of infrastructure that barely resemble each other. A load balancer's healthcheck, a Kubernetes probe, and an uptime monitor's healthcheck all serve the same underlying purpose (detect failure, trigger a response) but work in structurally different ways. So the honest answer to "what is a healthcheck" is: it depends which layer of your stack you're standing in. It's a pattern, not a single technology — and understanding the pattern is what lets you apply it correctly wherever you need it, including places most healthcheck tooling forgets to look.

The 3 Main Types of Healthchecks

Most healthcheck implementations fall into three buckets. Knowing which one you're dealing with saves a lot of wasted troubleshooting.

1. HTTP/API healthcheck endpoints. This is the classic pull-based model: a service exposes a route (commonly /health or /healthz), and something else — a load balancer, an uptime monitor, a REST API gateway — polls it on an interval. If the endpoint responds quickly with a healthy status, traffic keeps flowing. If it times out or returns an error, the poller marks the instance unhealthy and reacts. This is what most people mean by "http health check."

2. Container/orchestrator probes. Kubernetes formalizes healthchecks into three probe types, each answering a different question: liveness probes ask "is this container still running correctly, or does it need to be restarted?"; readiness probes ask "is this container ready to receive traffic right now?"; and startup probes ask "has this container finished its (possibly slow) initialization yet?" A container can be alive but not ready (still warming a cache, say), and treating those as the same signal causes bad restarts or premature traffic routing. Kubernetes' own documentation on liveness, readiness, and startup probes is the authoritative reference if you're configuring these directly.

3. Push-based heartbeat checks. Instead of something polling a service, the service itself reports in — "I'm alive, I finished my work" — on a schedule or after each run. If the expected ping doesn't arrive, the monitoring system assumes failure. This inverts the usual healthcheck direction: nobody has to ask the question, because the system volunteers the answer. See our deep dive on how heartbeat monitoring works for the full mechanics.

What a Good Healthcheck Endpoint Looks Like

If you're building an HTTP healthcheck endpoint from scratch, keep it simple. A minimal example:

GET /health

200 OK
{ "status": "ok" }

And when something's wrong:

GET /health

503 Service Unavailable
{ "status": "error", "detail": "database unreachable" }

A few best practices separate a good healthcheck from a fragile one:

• Keep it cheap and fast. A healthcheck endpoint shouldn't run heavy queries or call three downstream services just to answer "am I up?" A slow endpoint produces false negatives under load — exactly when you can least afford them.
• Use status codes meaningfully. 200 should mean genuinely healthy; 503 should mean genuinely not. Resist always returning 200 with a status field buried in the body — pollers and load balancers usually key off the HTTP status code, not the payload.
• Don't leak internals. Stack traces, connection strings, or internal hostnames in a healthcheck response are a gift to anyone probing your endpoints. Keep the response generic.
• Separate liveness from readiness where it matters. A process can be technically running while still unable to serve traffic. If your framework or orchestrator supports distinguishing the two, use both rather than collapsing them into one endpoint.

For a more detailed walkthrough of endpoint design, Ammune.ai's guide on REST API health check endpoints covers the tradeoffs well. If you're instrumenting healthchecks for Prometheus scraping, our Prometheus health check guide covers blackbox exporter setups and the gaps that approach leaves open.

Why Traditional Healthchecks Don't Work for Cron Jobs

Every healthcheck type described so far shares one assumption: something is listening, ready to answer when asked. A load balancer polls a running web server. Kubernetes probes a container that's supposed to be up continuously. An uptime monitor hits a URL and expects a response within seconds.

A cron job breaks that assumption entirely. It might run for eight seconds once a day, do its work, and exit — meaning there's nothing to poll for the other 23 hours and 59-plus minutes. You can't build a healthcheck for scheduled jobs the traditional way, because there's no listener to check. This gap trips up teams who assume their existing uptime tooling or load balancer healthchecks have them covered — they don't, because cron job health checking is a fundamentally different problem from server health checking.

The fix is to flip the model: instead of pulling a status, let the job push one. That's the heartbeat pattern from earlier, applied specifically to scheduled work. It's closely related to a dead man's switch — a monitor that stays silent as long as it keeps hearing from the job, and only alerts when the expected signal fails to arrive. Our explainer on dead man's switch monitoring for cron jobs walks through that mechanism in more depth.

Healthcheck Monitoring for Cron Jobs with Cronevra

Cronevra builds cron job monitoring around exactly this push model. Instead of polling a port that isn't listening most of the day, your scheduled job pings Cronevra when it starts, when it finishes, or both — and Cronevra tracks whether that ping arrives on time.

If a job succeeds, it reports in and the run is logged as healthy. If a job fails, hangs, or — critically — never runs at all because the scheduler itself broke, Cronevra notices the missing ping and fires a missed cron job alert before the failure snowballs into a bigger problem. That gives short-lived scheduled tasks the same pass/fail visibility a healthcheck endpoint gives a long-running web service, without pretending the job is something it isn't.

The Gap Cronevra Fills

Pull-based healthchecks — HTTP endpoints, load balancer probes, Kubernetes liveness and readiness checks — all assume something is reachable right now to answer a request. Cron jobs and scheduled tasks aren't listening on a port for almost their entire lifecycle, so that model simply can't monitor them. If your job silently stopped running last Tuesday, no load balancer would ever notice.

That's the exact gap Cronevra closes. Try Cronevra to get execution history, failure alerts, and recovery visibility for the scheduled jobs your current healthchecks can't see — or check the pricing page to see what fits your team.

Frequently Asked Questions

What is a healthcheck in simple terms?

A healthcheck is an automated check that answers "is this system working right now?" and triggers an alert or recovery action if the answer is no. It can be a load balancer polling an endpoint, a Kubernetes probe checking a container, or a service pinging in to confirm it's alive — the mechanism varies, but the goal is always early failure detection.

Is a healthcheck the same as a heartbeat check?

They're related but not identical: a healthcheck is typically pull-based (something asks the system for its status), while a heartbeat check is push-based (the system reports in on its own without being asked). Heartbeat monitoring is especially useful for things that aren't always reachable to be polled, like scheduled jobs.

What's the difference between liveness, readiness, and startup probes?

A liveness probe checks whether a container is still running correctly and should be restarted if not; a readiness probe checks whether it's currently able to serve traffic; a startup probe checks whether slow-starting containers have finished initializing before the other probes kick in. All three are Kubernetes-specific implementations of the general healthcheck pattern, and they answer different questions even though they sound similar.

What HTTP status code should a healthcheck return?

A healthy response should return 200 OK, and an unhealthy one should return 503 Service Unavailable, since most pollers and load balancers key off the HTTP status code itself rather than the response body. The body can carry extra detail, like a short status message, but it shouldn't leak sensitive internals such as stack traces or connection strings.

Can a healthcheck monitor a cron job?

Not with the traditional pull-based approach, because a cron job isn't listening on a port for most of the day and there's nothing for a poller to check. Instead, cron jobs need a push-based heartbeat or dead man's switch model, where the job itself reports success or Cronevra flags a missed run when no ping arrives by the expected deadline.

How often should a healthcheck endpoint be polled?

Most HTTP healthcheck endpoints are polled every 10-30 seconds by load balancers or uptime monitors, though the right interval depends on how fast you need to detect and react to failure. For push-based checks like cron job heartbeats, the "frequency" is really about how tight your deadline window is relative to the job's expected schedule.