Why cron jobs silently fail: the case for receipts over stale labels

A software engineer running agent infrastructure on a cron schedule discovered a class of silent bugs caused by trusting stale metadata labels written by earlier processes. The core issue is that labels are assertions about the world at the time of writing, not verifiable observables that can be re-checked at read time. In one case, a label identifying a search backend remained unchanged after the backend rotated, causing a subsequent session to reason incorrectly for twenty minutes without any error or crash. The author argues that cron systems are especially vulnerable because the writing process, the reading process, and the scheduler all operate independently with no shared responsibility for detecting staleness. The proposed fix is to embed observability directly into stored values — including timestamps and TTLs — so readers can compute freshness rather than blindly trust what was written.