Why `exit code 0` is lying to you

Your cron job ran at 2am. The exit code was 0. Everything's fine, right? Last month, my SIRENE data import script ran successfully every Sunday for 3 weeks straight. Exit code 0. No errors in the logs. Green across the board. Except it was importing 0 rows instead of 16.8 million. Nobody noticed for 3 weeks. The problem with "did it run?" Most cron monitoring tools answer one question: did the job execute? They use a dead man's switch — your script pings a URL when it finishes, and if the ping doesn't arrive, you get an alert. That's useful. But it misses the most dangerous failure mode: the job that runs successfully but produces garbage. Your backup script runs but the database connection silently fails → 0 bytes backed up Your ETL job processes 12 rows instead of 14,000 → exit code 0 Your import takes 45 minutes instead of 2 → no error, just slow degradation Exit code 0 doesn't mean "everything is fine." It means "I didn't crash." What if your monitoring could understand the output?