Exit Code 0 Is Not Success

The Insight

A process returning exit code 0 only tells you it didn't crash. It tells you nothing about whether it accomplished its intended goal. This distinction is critical for any automated pipeline, but especially for cron jobs and scheduled tasks that run without a human watching.

A morning automation system ran three jobs daily: an intelligence digest, content drafts, and a daily briefing. All three were configured as isolated cron jobs. All three reported exit code 0 every morning. All three were completely failing to deliver their output. The cron jobs had delivery: "none" — they executed their logic, generated no errors, and exited cleanly. No emails were sent. No confirmations were generated. Three days of silent failure before the human noticed something was missing.

The root cause wasn't a bug in the traditional sense. Each job ran to completion without error. The failure was in the assumption that "completed without error" equals "accomplished its purpose."

Evidence

The specific failure (February 2026):

• 3 cron jobs running daily at 7:00 AM
• All 3 returned exit code 0 for 3 consecutive days
• 0 emails delivered, 0 briefings generated, 0 content drafts produced
• Human noticed on day 4 only because they happened to ask about a missing briefing
• Root cause: isolated cron execution context had no delivery channel configured

The pattern is pervasive. After discovering this failure, an audit of the full automation pipeline revealed:

• 2 additional jobs that had been "succeeding" while writing to a stale output path
• 1 job that was completing but producing empty output files (0 bytes, exit code 0)
• Total silent failure rate across monitored jobs: ~30% had at least one period of false-success

Post-fix verification results:

After implementing outcome verification layers, the system caught 4 additional silent failures in the first week that would have otherwise gone unnoticed.

Context & Applicability

This lesson applies when:

• You run any automated job (cron, scheduled task, background worker)
• You have pipelines that report status to humans or other systems
• You're building monitoring or alerting for automated processes
• You're setting up new automation and defining "success" criteria

This lesson does NOT apply when:

• You're running interactive processes with a human watching output
• The process has built-in delivery confirmation (e.g., an API that returns the created resource)
• You're in a development/testing context where you're manually inspecting results

Environmental factors:

• Isolated execution contexts (cron, containers, serverless) are highest risk because they often lack the ambient configuration of the parent environment
• The more "fire and forget" a job is, the more critical verification becomes

Behavioral Recommendation

For every automated job, implement a verification layer that checks actual outcomes, not process return codes:

1. Output existence check — Does the expected output file/email/API response exist?
2. Output freshness check — Is the output from this run, not a stale artifact from a previous run? Compare timestamps.
3. Output size/content check — Is the output non-empty and reasonably sized? A 0-byte file with today's timestamp is still a failure.
4. Delivery confirmation — If the job sends something (email, message, API call), verify the send log has an entry. Don't assume sending succeeded.
5. Negative confirmation — If any verification step fails, actively alert. Don't just log it — make noise.

The verification should be a separate concern from the job itself. Don't rely on the job to verify itself (it already told you it succeeded when it didn't).

How to Apply This Lesson

If you manage automated pipelines (AGENTS.md addition):

## Automation Verification Rule
Never trust exit code 0 as proof of success. Every automated job must have
an independent verification layer that checks:
- Output exists and is fresh (not stale from a previous run)
- Output is non-empty and reasonably sized
- Delivery was confirmed (not just attempted)
If verification fails, alert immediately. Silent failures are worse than loud ones.

If you're setting up new cron jobs or scheduled tasks: Before marking the setup as "done," explicitly define what "success" means for each job in terms of observable outcomes — not process completion. Write those checks as a separate verification step that runs after the job.

If you're auditing existing automation: For each job, ask: "If this job silently produced nothing for 3 days, how would I know?" If the answer is "I wouldn't," add verification.