Find cron logs and detect missed jobs

Locate scheduler records, capture a task’s output and exit status, rotate its logs, and alert on failures or missing completion records.

Guance Editorial Team 2026-10-27 4 min read Updated 2026-10-27

Best practices

Cron's system logs can show when a command was launched and which account ran it. They do not universally include the command's exit status or application output. For useful troubleshooting, collect both scheduler records and task-level results.

A failed backup or missed certificate renewal may produce no obvious interactive error. Check for expected completion as well as explicit failures.

Find the scheduler logs

The destination depends on the operating system, cron implementation, and logging configuration:

Environment	Common destination	Example inspection
Debian/Ubuntu with matching syslog rules	`/var/log/syslog`	`grep CRON /var/log/syslog`
RHEL-family systems with matching syslog rules	`/var/log/cron`	`tail -f /var/log/cron`
systemd journal	The cron service's journal	`journalctl -u cron` or `journalctl -u crond`
Modern macOS	Unified logging, where cron emits relevant records	`log show --predicate 'process == "cron"' --last 1h`

Do not assume a text file exists simply because the distribution commonly uses it. On Debian-style systems that do write /var/log/syslog, follow cron entries with tail -f /var/log/syslog | grep CRON.

Read a launch record

Apr 20 14:00:01 myserver CRON[1234]: (root) CMD (/usr/local/bin/backup.sh)

The fields identify the timestamp, host, cron process ID, execution account, and event. CMD records a command launch. Some implementations or logging modes also record completion or exit status; a FINISHED line is not portable across cron implementations.

A launch record does not prove that the backup succeeded.

Capture the task's own output

0 2 * * * (date; /path/to/backup.sh) >> /var/log/backup.log 2>&1

>> appends standard output, and 2>&1 directs standard error to the same destination. The initial date adds a run timestamp. Ensure the account can write the file.

For machine-readable status markers, the script can preserve the real exit code:

#!/bin/bash
echo "===== started at $(date '+%F %T') ====="
status=0
if tar -czf /backup/data.tar.gz /var/www/data/; then
    echo "[SUCCESS] backup created"
else
    status=$?
    echo "[ERROR] backup failed exit_code=$status"
fi
echo "===== finished at $(date '+%F %T') ====="
exit "$status"

The example reuses one archive path. Real backup policy also needs retention, restore testing, and protection against overwriting a known-good backup with a failed run.

Rotate the log, for example through /etc/logrotate.d/custom-cron:

/var/log/backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Confirm file ownership and creation behavior for the actual task account. A task that keeps a file open across rotation may require additional coordination.

Detect a missing completion

Define a deadline for each important task. For a backup scheduled at 02:00 and expected to finish by 03:00:

Configure DataKit log collection for /var/log/backup.log, including host and task identifiers.
Use a log detection rule to detect [ERROR] results.
Separately check for [SUCCESS] within the intended run window after the completion deadline. Enable the required missing-data behavior; a rule configured to produce no event for missing data will not report a missed run.
Skip a test execution deliberately, verify the missing-completion alert, then restore the task and check recovery behavior.

A missing log can mean the task did not run, the task did not finish, or collection failed. Preserve enough signals to investigate those separately.

Protect operational logs

Use file permissions appropriate to the task and collector. For example, root:adm ownership and mode 640 fit some Linux configurations, but the group must exist and have the intended access.

Do not print passwords or API keys. If local collection-time processing redacts sensitive fields, test the transformation with representative records before sending them onward. Cron implementations may log crontab replacement or edit events, but those events alone are not a complete audit trail of the changed contents.

FAQ

Where does unredirected output go?

Cron commonly attempts mail delivery according to MAILTO and local mail configuration. If no working mail path exists, do not assume the output will reach anyone. Capture it explicitly.

How do I separate standard output and standard error?

/path/to/script.sh >> /var/log/task-out.log 2>> /var/log/task-err.log

This appends to both files. Error details may still be written to stdout by the application, so inspect its logging behavior.

There is no CMD record. What should I check?

Check the service (cron or crond), the configured log destination, crontab syntax, and whether the expected account owns the entry. Then check paths, environment, permissions, and any conditions that prevent the task from starting.

Can Guance detect a task that produced no log?

A missing-data check on expected completion records can detect that condition if configured for the proper window. Test it with a deliberately missed run, and do not interpret every idle interval as a failure.