Most cron monitoring is a single ping: the job says “I ran” and the monitor believes it. That catches a job that stopped running entirely, and nothing else. Atlas tracks each run as a lifecycle — start, then finish or fail — so the record has a duration, an exit code, and a shape you can compare against last week.
Success rate (last 30)
93%
Last duration
4m 12s
Consecutive failures
0
Last run
3h ago
Recent runs
Every run, its duration and its real exit code — including the one that lied.
Both of these look identical to a ping-based monitor, because in both cases the ping that would have told you never arrives — or arrives and says everything is fine.
A run can report itself over a ping, and the agent on the host can observe the same run independently. When both exist, Atlas reconciles them.
That produces one alert nothing else on the market can raise: the job reported success over its ping, but the host shows it exited 1. It is a common failure — a wrapper script that swallows the exit code of the thing it wrapped, a pipeline where only the last command’s status survives, a trap that fires on the wrong signal. The job cheerfully tells you it worked every night while quietly doing nothing.
Host evidence
systemctl show call. That means a systemd-managed job is monitored with zero changes to the job itself — no wrapper, no ping, no edit to a script you would rather not touch.The agent reads the user crontabs on each host and reports what it finds, so the Scheduled Jobs tab shows the jobs that actually exist — including the one a contractor added in 2023 that nobody has thought about since.
Discovery is deliberately limited to user crontabs. Distro housekeeping — apt-daily, man-db, logrotate — is filtered out, because a list where the ten jobs you care about are buried under forty you do not is a list nobody reads.
Turning one into a monitor is a button. Atlas maps the cron expression to a schedule and hands back the exact replacement crontab line.
The shell wrapper sits in front of your command and reports around it. Your script is untouched — Atlas observes workloads, it does not rewrite them.
$0 3 * * * zuvio-run --slug nightly-backup -- /opt/backup.sh
Start, finish, duration and exit code, reported around your unchanged command.
The wrapper is a convenience over three public endpoints. Zero-dependency clients exist for Node, Python, PHP (with a Laravel scheduler macro) and POSIX shell, all best-effort by design — a monitoring outage must never take down the job it is watching.
start — opens a run and returns its id.finish — closes it successfully, with duration and exit code.fail — closes it as failed; a streak of these fires once at your threshold, not once per night.Full request and response reference, including the SDK payloads, is in the API documentation.