Cron job monitoring

Know when a cron job did not finish on time.

LatidoFlow uses completion heartbeats and expected windows to surface silent cron failures. A configured schedule is not treated as proof that the workload executed.

The direct answer

Call a unique heartbeat URL only after the cron job completes. LatidoFlow starts the deadline timer after the first valid ping. Every later completion resets the next expected window; when that window and its grace period pass without evidence, the evaluator opens a missing-run incident.

This pattern works for any cron host or script that can make an HTTP request. Use GET for a simple completion signal. Use POST when the workload must attach metadata or typed output for assertions.

A minimal completion flow

# Run the real workload first
php /srv/app/bin/import-invoices.php

# Send completion evidence only after it succeeds
curl -fsS "https://www.latidoflow.com/heartbeat/{monitor_uuid}/{token}"

The URL contains monitor credentials and should be kept secret. A GET heartbeat cannot send typed output. When an output contract is configured, report the result with POST instead.

What the signal tells you

Missing completion

No valid ping by the expected time plus grace is evidence that the run is missing, late, or unable to report.

Received completion

A valid ping records a run and advances the next expected window. Metadata is stored after secret redaction.

Recovery

A later valid completion can recover the monitor and resolve the open missing-run incident.

What a completion ping does not prove

A basic heartbeat proves that code reached the ping. It does not by itself prove that invoices were imported, rows were exported, or notifications were sent. Add a POST output metric and assertion when business output matters, and keep uptime monitoring separate when you also need public HTTPS checks.

Keep exploring

Monitor one silent cron failure

Start with a scheduled workload that currently has no independent completion signal.