The env file said DRY_RUN=false. The job ran in dry-run mode anyway, and it kept doing that long enough to matter.
This was the collections side of a lending system: the service that sends payment reminders, escalates warnings, and queues calls for the people who go quiet.
The flag arrived as a string. The code did a truthiness check on it. "false" is a non-empty string, so every value anyone could possibly put there meant yes.
Nothing broke.
No exception. No failed task. No alert. The scheduler fired on time, the task finished green, and it logged how many accounts it had evaluated. It just never sent anything to anyone.
The cost was not technical. Accounts that needed a first gentle nudge got nothing, drifted past the stage where a reminder still does its job, and landed in the expensive part of the process instead. The fix was one line and took a minute. Explaining the silence took considerably longer.
Two things changed in how I build after that.
Flags go through one parser with an explicit allowlist, and an unrecognized value fails startup. A service that cannot say for certain whether it is live has no business booting.
And side-effectful jobs alert on absence, not only on errors. If the reminder sender sends zero for a full cycle, that is a page, because "succeeded and did nothing" looks identical to "succeeded" in every dashboard I have ever been handed.
Error monitoring catches the code that runs and fails. It has nothing to say about the code that runs and declines to act.
So it is worth knowing what your monitoring does when a job completes cleanly and produces no effect at all...