An external HTTP scheduler and a heartbeat monitor solve different reliability problems. This guide explains how to choose the right model—and when to combine them.
AI-assistance disclosure: This article was prepared with AI assistance and reviewed by the CronPulser Team for technical accuracy.
“Monitor this cron job” sounds like one problem. In practice, it can describe two different architectures:
- A scheduler starts the work.
- A monitor waits for evidence that independently scheduled work happened.
Both can improve reliability, but they observe different boundaries. Choosing the wrong model can leave you with a green dashboard that does not prove what you think it proves.
The quickest way to distinguish them is to ask:
Who owns the trigger?
Model 1: an external scheduler initiates the HTTP request
An HTTP cron scheduler owns the schedule and actively calls an endpoint when the schedule becomes due.
external scheduler
|
| POST /internal/jobs/reconcile
v
application endpoint
|
| HTTP status + response
v
execution history
This works well when the recurring operation already has a safe HTTP entry point: a webhook, maintenance route, synchronization endpoint, or report-generation API.
The scheduler can directly observe transport-level facts such as:
- whether DNS resolution and connection setup succeeded;
- whether the request timed out;
- which HTTP status code came back;
- how long the request took;
- whether a retry was attempted.
But it sees only the request boundary. If the endpoint returns 202 Accepted after putting work on a queue, the scheduler has proved that dispatch was accepted—not that the queued task eventually finished.
That distinction matters.
Model 2: a heartbeat monitor observes an existing job
A heartbeat monitor does not usually start the job. Your own cron daemon, CI platform, workflow engine, or application timer remains responsible for execution. The job then sends a signal to the monitor.
cron daemon
|
v
local script -------- success/failure ping --------> monitor
A basic setup sends a success ping only after the command completes:
if ./nightly-backup.sh; then
curl --fail --max-time 10 "$HEARTBEAT_URL"
fi
If the signal does not arrive within the configured grace period, the monitor alerts.
More expressive implementations send separate start, success, and failure signals:
curl --fail --max-time 10 "$HEARTBEAT_URL/start"
if ./nightly-backup.sh; then
curl --fail --max-time 10 "$HEARTBEAT_URL"
else
curl --fail --max-time 10 "$HEARTBEAT_URL/fail"
exit 1
fi
This lets the monitor distinguish “never started” from “started but did not finish on time.” Healthchecks.io documents this start/success pattern and treats a missing success after a start as a failure. Cronitor exposes similar run, complete, and fail lifecycle signals.
The job still runs without the monitoring service initiating it. That makes heartbeat monitoring a natural fit for private scripts, backups, database maintenance, CI workflows, and other tasks that already have an execution environment.
The failure modes are not identical
Neither architecture is automatically more reliable. Each gives you evidence from a different point in the system.
The machine is offline
A heartbeat monitor notices that the expected signal never arrived. This is one of its strongest use cases: the dead machine cannot report success.
An external HTTP scheduler may record a connection failure if the target should be reachable. If the work exists only as a private local script with no reachable endpoint or agent, the scheduler cannot start it.
The job starts and hangs
A completion-only heartbeat eventually becomes late, but it cannot prove whether the job never started or started and stalled. Start/success lifecycle signals make that diagnosis clearer.
An HTTP scheduler can enforce a request timeout. However, a client-side timeout does not prove that server-side work stopped. The server may continue processing after the scheduler gives up.
The work succeeds, but the heartbeat ping fails
The monitor may report a failure even though the underlying work completed. The telemetry network call is a second operation with its own failure modes.
This is why heartbeat clients commonly use a short timeout and retries for the ping—but must not let a monitoring outage prevent the primary job from running.
The endpoint performs work, but its response is lost
An HTTP scheduler may not know whether the server completed the operation before the connection failed. Blindly retrying a non-idempotent operation can execute it twice.
HTTP defines some methods as idempotent by intended semantics, but POST is not inherently idempotent. Scheduled write endpoints should therefore support an application-level idempotency key or another deduplication mechanism.
The application returns success too early
A 200 response can be technically successful while the business operation is wrong. A heartbeat can also be sent even though the resulting data is incomplete.
Neither model replaces business-level validation. For important jobs, verify an outcome such as:
- expected rows reconciled;
- a report artifact created;
- a queue item completed;
- a backup passed an integrity check;
- a downstream system acknowledged the update.
A practical decision guide
Choose an external HTTP scheduler when:
- the work can safely begin through an authenticated HTTP endpoint;
- you want scheduling outside the application process;
- request status, latency, timeout, and retry evidence are useful;
- you do not want to maintain a separate cron host;
- central management of headers, schedules, and execution history is valuable.
Choose heartbeat monitoring when:
- a job already runs through cron, systemd, CI, Airflow, Kubernetes, or another scheduler;
- the command must stay on a private machine;
- opening an inbound endpoint would add unnecessary risk;
- you mainly need to know whether the existing job started, completed, failed, or went missing.
Use a hybrid when:
- an HTTP call only enqueues asynchronous work;
- the first request and final business outcome need separate evidence;
- a private runner or agent receives scheduled instructions over an outbound connection;
- the operation is important enough to monitor both dispatch and completion.
A hybrid is often the honest answer. One signal proves that work was requested; another proves that the intended outcome occurred.
Reliability checklist for either model
Before trusting a recurring production task, verify these points:
1. Authentication
Protect scheduled endpoints with a dedicated secret, signed request, or narrowly scoped credential. Do not rely on an obscure URL alone.
Treat heartbeat URLs as secrets too. Anyone who can call one may be able to create false success signals.
2. Idempotency
Assign each scheduled occurrence a stable execution identifier. If a timeout or network failure makes the result ambiguous, a retry should not duplicate invoices, emails, payouts, or destructive maintenance.
3. Timeouts and overlap
Set a maximum execution time and decide what happens when the next occurrence becomes due while the previous one is still running:
- skip;
- queue;
- run concurrently;
- cancel and replace.
Leaving this undefined is how “every five minutes” becomes twenty concurrent copies after a downstream slowdown.
4. Explicit success
Avoid treating “the process exited” or “the endpoint returned” as sufficient for critical work. Validate the outcome you actually care about.
5. Independent no-execution detection
The component that schedules work can fail too. A no-execution detector should compare the expected schedule with actual execution records rather than creating synthetic successful runs.
6. Safe observability
Log execution identifiers, timestamps, duration, status, and bounded diagnostic output. Redact credentials and personal data. Monitoring should reduce incident risk, not create a new secret store.
Why we care about the distinction
CronPulser uses the execution-owning model for HTTP jobs: it initiates the scheduled request and records the result. For private commands, its Runner uses an outbound connection rather than exposing inbound SSH. It is not a generic heartbeat-ingestion endpoint.
That architecture is one option, not a universal replacement for heartbeat monitoring. The right choice depends on where the work lives and which boundary you need to prove.
If your task already runs reliably on its own machine, add lifecycle-aware heartbeat monitoring. If the task is naturally an authenticated HTTP operation and you want an external system to own the trigger, use an HTTP scheduler. If dispatch and completion are separate, monitor both.
