Skip to main content

Monitoring cron

cron is recognised by its daemon process, and the agent then does two things with no configuration: it counts what cron writes to the journal into rates, and it keeps an inventory of every scheduled entry it finds on the host. Whether one specific job ran is a different question, answered by heartbeats in the console; the last section explains the split.

How cron is recognised​

Two definitions cover the two daemon names: cron matches a running cron process (Debian, Ubuntu and their derivatives), crond matches crond (the RHEL family). Both apply to systemd hosts and read the journal, the first under the identifiers CRON and cron, the second under CROND and crond. Every minute the new entries since the last read are counted into three per-second rates.

Independently of the definition, host discovery enumerates the scheduled entries themselves: the system crontab, /etc/cron.d, the per-user spools, and the cron.hourly through cron.monthly directories. Each entry lands in the inventory keyed by user and command, with its schedule.

What is collected​

Runs. Every job start cron logs (the CMD (...) lines), as a rate.

cron's own errors. Lines that carry the word error, such as a user that does not exist or a crontab cron cannot parse: cron reporting a problem of its own.

Failed jobs. Lines that report failed with exit status, which cron writes when a job exits non-zero. They are counted on their own so that a job that keeps failing is a signal in its own right, distinct from cron being broken.

SignalMetric
Job starts per secondsvc.cron.runs_rate
cron errors per secondsvc.cron.error_rate
Jobs exiting non-zero per secondsvc.cron.job_failed_rate

Names, tags and units are in the metrics reference.

Logs. cron's journal lines are part of the system log stream (the cron, CRON and crond identifiers of the logs-system definition), notice level and above by default. See Monitoring systemd and Logs.

Alerts out of the box​

RuleFires whenSeverityShips
Cron jobs keep failingjobs exit non-zero at 0.005 per second or more (roughly one failure every three to four minutes) for 15 minuteswarningoff

The rule ships off because how many failures are normal depends entirely on your crontab: a job written to retry until it succeeds fails by design several times an hour, and on a box with hundreds of entries the same rate can be nothing or everything. Enable it per workspace, or per host, once you know what your baseline looks like; the threshold and the 15-minute hold are editable in place. The metrics above can also drive a custom rule of your own. Details are in the rules catalog.

When a job goes silent: heartbeats​

The rates above tell you that cron ran things and how many of them exited non-zero, as far as the log shows; they cannot notice a job that never started, because a deleted crontab line or a stopped daemon produces no line to count. For that the console offers cron heartbeats: the job fetches a per-job URL as its last step, and silence past the expected interval plus a grace period opens an incident for that job, with nothing to configure on the agent side.

Limitations​

  • The rates exist on systemd hosts only, because they are read from the journal. OpenRC and sysvinit hosts still get the inventory of entries and still ship their system log.
  • The counters do not say which job failed; the surrounding lines in the log stream do.
  • cron mails a job's output rather than logging it, so the agent never sees what a job printed. Its exit status is the only verdict available.
  • Jobs run by systemd timers or anacron are not cron entries and are not counted here.
  • The inventory lists what is scheduled, not what ran. For positive confirmation of a run, use a heartbeat.