Monitoring Check Types Explained: Which One Catches Cron

Most people say "monitoring check" and mean one thing: a bot pinging their homepage every five minutes. That's a fraction of the picture. A monitoring check is really an umbrella term for any automated probe that verifies a system, service, or job is behaving as expected — and once you see it that way, it's clear a single uptime ping can't cover everything you're running.

This article builds the full taxonomy, then answers the question most guides skip: which type of monitoring check actually catches a cron job that silently failed to run.

What Is a Monitoring Check, Exactly?

A monitoring check is an automated verification — scheduled or continuous — that confirms a system is alive, correct, or complete, and raises an alert when it isn't. The differences between check types come down to what they verify and how they get their data.

The most useful split is pull vs. push, which maps closely to what the Google SRE book calls black-box vs. white-box monitoring. A pull-based, black-box check works from the outside: a monitoring service reaches out to your system — an HTTP request, a ping, a DNS lookup — and judges health purely by the response, with no view into what's happening internally. Uptime checks, health checks, and synthetic checks are all pull-based.

A push-based check flips the direction: instead of something reaching in to ask "are you alive?", your system reaches out to report "I just ran, and here's how it went." Nothing polls it, because there's often nothing to poll. This is the model heartbeat monitoring uses, and it matters once you start monitoring background work instead of public-facing pages.

The 4 Main Types of Monitoring Checks

• Uptime/ping checks — Pull-based. Periodically request a URL or send an ICMP ping and check for a response within a timeout. Blind spot: confirms the server answers, but says nothing about whether the application logic behind it is correct. The UptimeRobot guide to monitoring types covers HTTP, ping, DNS, and keyword variants in more depth.
• Health checks — Pull-based, but smarter. A dedicated health check endpoint reports internal state — database connections, queue depth, disk space — often as structured JSON. It's the difference between "the server responded" and "the server is actually able to do its job." We cover this distinction fully in our health check test guide and go full-stack in this piece on system health checks. Blind spot: only reports state at the moment it's asked; it can't tell you a background process silently stopped.
• Synthetic checks — Pull-based, but scripted. Instead of hitting one endpoint, a synthetic monitor simulates a real user flow — login, add to cart, checkout — on a schedule, catching multi-step regressions a single ping would miss. Blind spot: still requires something reachable to click through; it can't test a process with no UI or URL.
• Heartbeat checks — Push-based. The job itself sends a signal when it completes, and the monitoring service alerts you if that signal doesn't arrive on schedule. Also called a dead man's switch, a term borrowed from failsafe engineering: absence of a signal is the alert. Pulsetic's explainer on heartbeat monitoring lays out this push model clearly.

Health check vs. monitoring check is a category-vs-member relationship: health checks are one type of monitoring check, alongside uptime, synthetic, and heartbeat. The confusion comes from people using "monitoring check" loosely to mean whichever one they set up first.

The Blind Spot: Why None of These Catch a Silent Cron Failure

Uptime, health, and synthetic checks share one requirement: something to poll — a URL, an IP, a port a monitoring service can reach and inspect. That works fine for a website, an API, or a container, which is also why Docker healthcheck configuration can confirm a container process is running without ever confirming the cron job inside it actually fired.

A scheduled job — a nightly backup script, a report generator, a data sync — usually has no endpoint at all. It wakes up, does work, and exits, with nothing sitting there to answer a pull request between runs. So when that job fails to fire — a bad deploy, a disabled crontab entry, a crashed process — every pull-based check stays green, because a job that never ran and a job that isn't scheduled look identical from the outside. This is the silent cron failure problem, and it's the specific gap a monitoring check for cron jobs needs to close.

Push-based heartbeat monitoring solves it by inverting who initiates contact. The job pings a unique URL when it starts or finishes; if that ping doesn't arrive within an expected window, you get alerted. No inbound endpoint required, because the job is reporting on itself. This distinction, push vs. pull monitoring, is the single most important thing to understand if any part of your system runs on a schedule rather than in response to a request. It's also relevant if your jobs run across multiple machines or workers, covered in our guide to distributed job scheduling.

How to Choose the Right Monitoring Check

A simple decision framework, roughly in order of what to check first:

• Public-facing URL or API → uptime/ping check.
• Internal service state (DB connections, dependencies, resource limits) → health check.
• Critical multi-step user flow (checkout, signup, login) → synthetic check.
• Anything scheduled or background with no inbound URL (cron jobs, workers, batch scripts) → heartbeat check.

Most production systems need a combination, not one silver bullet. A typical stack runs uptime checks on the main site, health checks on backend services, synthetic checks on the checkout flow, and heartbeat checks on every cron job and background worker. Skipping the last category is the most common gap, because teams assume their existing pull-based coverage extends to scheduled tasks — it doesn't.

Setting Up a Monitoring Check for a Cron Job in Minutes

Closing the gap doesn't require new infrastructure:

1. Create a unique heartbeat URL for the job.
2. Add a single line to the script — a curl call to that URL — so it pings on success (and optionally on start).
3. Set the expected schedule and a grace period (how late a run can be before it's considered missed).
4. Get alerted the moment a ping doesn't arrive on time, instead of finding out days later when a report never showed up.

If your current setup relies on cron's built-in MAILTO output, it's worth knowing why that approach breaks down — mail delivery is unreliable, and a failed job with no email sent is indistinguishable from a job that succeeded quietly.

Frequently Asked Questions

What exactly counts as a 'monitoring check'?

A monitoring check is any automated probe that verifies a system, service, or job is working as expected and raises an alert when it isn't. It's an umbrella term covering uptime checks, health checks, synthetic checks, and heartbeat checks — not a synonym for any single one of them.

What are the main types of monitoring checks and how do they differ?

The four main types are uptime/ping checks (confirm a server responds), health checks (confirm internal service state), synthetic checks (simulate a user flow end-to-end), and heartbeat checks (confirm a scheduled job actually ran). They differ mainly in what they verify and whether they're pull-based or push-based.

What's the difference between a pull-based check and a push-based check?

A pull-based check has a monitoring service reach out to your system and inspect the response, which requires an inbound endpoint to poll. A push-based check flips this: your system reaches out to report that it ran, which works even when there's no endpoint to poll at all — the model heartbeat monitoring uses.

Why don't uptime or health checks catch a cron job that silently failed to run?

Uptime and health checks are pull-based and need something to poll, but a scheduled job typically has no endpoint sitting between runs. A job that never fires looks identical to a job that simply isn't scheduled, so pull-based checks stay green while the job silently fails.

How do I decide which type of monitoring check to use for a given service or job?

Use uptime checks for public URLs, health checks for internal service state, synthetic checks for critical multi-step user flows, and heartbeat checks for anything scheduled or background with no inbound URL. Most real systems need a combination of all four rather than relying on just one.

Most teams already have uptime and health checks covering their websites and APIs, and assume that's full coverage — but every cron job and scheduled task with no inbound endpoint sits completely unmonitored underneath it. Set up a heartbeat-style monitoring check for your cron jobs with Cronevra and get alerted the moment one fails to run, instead of finding out from a customer.