Missing completion
No valid ping by the expected time plus grace is evidence that the run is missing, late, or unable to report.
Cron job monitoring
LatidoFlow uses completion heartbeats and expected windows to surface silent cron failures. A configured schedule is not treated as proof that the workload executed.
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.
# 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.
No valid ping by the expected time plus grace is evidence that the run is missing, late, or unable to report.
A valid ping records a run and advances the next expected window. Metadata is stored after secret redaction.
A later valid completion can recover the monitor and resolve the open missing-run incident.
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.
Start with a scheduled workload that currently has no independent completion signal.