⏰ Using AI to Review a Cron Job Before It Runs in Prod

A cron job is automation with the worst possible failure mode: it runs unattended, fails quietly, and nobody notices until the thing it was supposed to do hasn’t happened for a week. I’ve started running every new cron script through an AI review before it ships, and it catches the boring, dangerous problems — overlapping runs, swallowed output, naive timestamps — that I’d otherwise discover during an incident. The AI is a fast junior reviewer here: thorough, occasionally wrong, and never a substitute for a human reading the final diff before it touches prod.

Give the AI the crontab line and the script

Half of cron bugs live in the schedule, not the code. So I paste both the crontab entry and the script, and ask: “Review this cron job for reliability problems — scheduling, concurrency, logging, and failure handling.”

*/5 * * * * /opt/jobs/sync_inventory.sh >> /var/log/sync.log 2>&1

For this one the AI immediately flagged that a sync taking longer than five minutes would overlap with the next run, and that there was no alerting if the job died. Both true. It read the schedule and the script together, which is exactly the cross-cutting analysis a fast reviewer is good at.

Prevent overlapping runs with a lock

The overlap problem is the classic cron killer. The AI’s fix was flock, which I reviewed and adjusted.

#!/usr/bin/env bash
set -Eeuo pipefail

exec 9>/var/run/sync_inventory.lock
if ! flock -n 9; then
    echo "[INFO] previous run still active, skipping" >&2
    exit 0
fi

# ... actual work runs here, lock auto-released on exit

flock -n makes a second invocation exit immediately rather than queue up. The AI proposed flock -w 300 (wait up to five minutes), which is exactly wrong for a five-minute schedule — you’d build a backlog. I switched it to -n to skip instead of wait. The AI’s instinct to “be patient” is the wrong default for cron; you almost always want skip-if-running. See file locking and signal handling for safe scripts for the deeper treatment.

Don’t trust cron’s environment

Cron runs with a minimal PATH and none of your shell profile. Scripts that work in your terminal break in cron because aws or python3 isn’t found. I ask the AI to “make this robust to cron’s minimal environment.”

PATH="/usr/local/bin:/usr/bin:/bin"
export PATH

PYTHON="$(command -v python3)"
[[ -x "$PYTHON" ]] || { echo "python3 not found" >&2; exit 1; }

The AI knows this gotcha well and handles it cleanly. I still verify the actual paths against the target host — the AI guessed /usr/local/bin which happened to be right for us but is a guess, not knowledge of our system.

Pro Tip: ask the AI “what environment variables does this script assume exist that cron won’t provide?” It’ll list HOME, PATH, LANG, and any sourced profile vars — the exact set that makes a script work interactively and die in cron.

Make failures loud

A cron job that fails silently is worse than no job. The AI suggested capturing failures and alerting, not just logging. The key insight it surfaced: >> /var/log/sync.log 2>&1 captures output but nobody reads that log until something’s already wrong.

notify_failure() {
    local msg="$1"
    # Post to your alerting webhook; never embed the secret here
    curl -fsS -X POST "$ALERT_WEBHOOK" \
         --data-urlencode "text=sync_inventory failed: $msg" || true
}
trap 'notify_failure "line $LINENO"' ERR

The $ALERT_WEBHOOK comes from the environment, never hardcoded. This connects cron jobs to the same alerting you’d use elsewhere — the monitoring alerts dashboard and incident response dashboard are where these notifications should land so a failed 3am job actually pages someone.

Use UTC and explicit timezones

Cron honors the system timezone, and the AI caught that my Python job built date strings with datetime.now() — local time — while the database stored UTC. That mismatch had been silently selecting the wrong day’s data near midnight.

from datetime import datetime, timezone

run_date = datetime.now(timezone.utc).date()

This is the kind of subtle correctness bug a fast reviewer spots by reading carefully. I confirmed it against our actual DB convention rather than taking the AI’s word — it was right, but I verify timezone claims because they’re easy to get backwards.

Consider whether cron is even the right tool

Sometimes the best review outcome is “don’t use cron.” I ask the AI to compare cron against systemd timers for the job. For anything needing dependency ordering, resource limits, or proper logging via journald, it recommends timers — correctly. The tradeoffs are laid out in scheduling scripts: systemd timers vs cron, and the AI’s summary tracks that guide closely.

Keep secrets and prod data out of the review

When I share a cron script for review, I scrub the webhook URL, any tokens, and any real hostnames to placeholders like __ALERT_WEBHOOK__. The AI reviews the structure and logic without ever seeing a live credential. It’s a fast junior reviewer; you don’t give a junior contractor the production secrets on day one, and you don’t give them to an AI either.

Conclusion

Cron jobs fail in the dark, so reviewing them before they ship matters more than for code anyone watches. AI catches overlap, missing locks, environment assumptions, silent failures, and timezone bugs at junior-engineer speed — and occasionally proposes the wrong fix, like waiting on a lock it should skip. Feed it both the schedule and the script, review every suggestion against your real environment, route failures to real alerting, and keep secrets out of the prompt. The final read before it runs on prod is yours. More cron and scheduling prompts live in the bash and Python automation category and the prompts library.