The cron job that never ran (or ran wrong): PATH, percent signs, and the environment your scheduler does not have

verbatim error# crontab entry: 15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 # observed: script exists, runs fine by hand, produces nothing at 3:15. No log, no error. # and the date-in-cron variant: 45 2 * * * /usr/local/bin/cleanup.sh --before=$(date +%Y-%m-%d) # executed literally: "--before=%Y-%m-%d"

Problem

A backup cron entry, hand-verified by running the script directly, silently did nothing at 3am:

# crontab entry:
15 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
# observed: script exists, runs fine by hand, produces nothing at 3:15. No log, no error.
# and the date-in-cron variant:
45 2 * * * /usr/local/bin/cleanup.sh --before=$(date +%Y-%m-%d)
# executed literally: "--before=%Y-%m-%d"

"Runs fine by hand" is the trap: cron runs your command in a nearly empty environment, and several of its failure modes produce no output at all.

Root cause

Three cron-specific behaviors, all biting at once:

1. PATH is /usr/bin:/bin — commands installed in /usr/local/bin, or interpreted via pyenv/nvm shims, vanish. Scripts that worked in your shell called aws, node, or pip by bare name. 2. % is special in crontab: an unescaped % starts the stdin payload of the command. Every %Y in that date string became "everything after this goes to stdin", so the command ran with mangled arguments — or never ran. 3. No mail target configured: cron's only error channel is mail; with MAILTO unset and no local MTA, failures vanish.

fix preview — first 3 of 6 lines (bash), truncated:

#!/bin/bash
# /usr/local/bin/backup-wrapper.sh
set -euo pipefail
… 3 more lines in the fix

🔒 the fix — including 4 code blocks — is members-only. $1/mo unlocks everything.