Quick Answer
Cron jobs fail in three quiet ways: they overlap when a run takes longer than its interval; they hang when a command blocks on a dead socket or lock and never exits; and they die on a transient blip that would have succeeded on a second try. This tool composes the three guards: flock holds a kernel lock so only one copy runs at a time (and the kernel frees it on crash or kill, no stale PID files), timeout sends SIGTERM at a deadline and SIGKILL after a grace period for processes stuck in uninterruptible I/O, and a retry loop with exponential backoff and jitter survives a flaky network or a not-yet-ready dependency without hammering the recovering service. Toggle any combination, set the schedule, and get a ShellCheck-clean wrapper script and the crontab line that calls it.
Run this script on a real Linux server
Get $200 free credit — DigitalOcean
Get $200 Free →Affiliate link · we earn a commission
Need a domain for your next project?
Register with Namecheap — free WHOIS privacy included
Check Domain Prices →Affiliate link · we earn a commission
6 scripts + shared library + 52-page field guide. The production layer the free snippets don't cover.
Get the Toolkit →What is the difference between this and the Cron Job Builder?
The Cron Job Builder builds the cron schedule expression — the five-field timing string. This tool builds the wrapper script that runs when the schedule fires. They're designed to be used together: build the schedule there, build the hardened script here, paste both into crontab -e.
Why does the crontab line change when I turn on retry or alerting?
Lock and timeout are simple enough to inline directly on the crontab line — a one-liner with flock and timeout in front of the command. Retry and email alert require a bash function and mailx call, which can't fit on a crontab line. When either is on, the output switches to a wrapper script and a crontab line that calls it.
What does SIGKILL grace mean?
timeout first sends SIGTERM — a polite signal a well-behaved program uses to clean up and exit. But a process blocked in uninterruptible I/O (disk or NFS) physically cannot act on SIGTERM. SIGKILL grace is how long timeout waits after SIGTERM before sending SIGKILL, which the kernel enforces unconditionally. Set it to 15–30 seconds.
Should I use Skip if busy or Wait for the lock mode?
Skip if busy (-n) is right for frequent cron jobs where a missed run is harmless — a metrics push, a sync that catches up next minute. Wait then give up (-w) is for jobs that must run eventually but can tolerate a short queue. Never leave the lock in blocking mode with no timeout on a frequent schedule.
Where should the lock file live?
/run/lock is the right location on any modern systemd system — it is a tmpfs cleared cleanly on reboot, so you never inherit a stale lock across a reboot. The tool generates the lock path from the job name automatically. Avoid /tmp: systemd-tmpfiles periodically deletes old files there and can delete a lock mid-run.
intermediate · flock
Prevent Overlapping Cron Jobs with flock
A cron job that runs long overlaps the next run and stacks copies until the box falls over. Lock it to a single instance with flock — a kernel-held lock that releases on crash, no stale PID files.
intermediate · timeout
Stop a Hung Command with timeout
A hung cron job is worse than a failed one — it never exits, never frees its lock, and the job silently stops running. Bound any command's runtime with timeout, escalate to SIGKILL, and read the exit code.
intermediate · retry
Retry a Command with Exponential Backoff in Bash
A deploy that dies on the first transient error wastes your night re-running it by hand. Retry with exponential backoff and jitter — and learn which failures to retry and which to fail fast on.
A single command and its arguments. For a pipeline or several commands, enter bash -c 'cmd1 | cmd2'.
Stops a long run from overlapping the next one and stacking copies.
Kills a hung run so it can't hold the lock and jam every future run.
Survives a blip or a not-yet-ready dependency instead of dying on the first error.
Cron discards output by default. Write what happened to a file you can read.
Sends mail only when the job fails after its retries. Requires mailx configured.
Need help with the expression? The Cron Job Builder builds it visually.
#!/bin/bash
# Script: safe-rsync.sh
# Purpose: Run a cron job safely — single-instance, time-bounded
# Generated by https://bashsnippets.xyz/tools/cron-wrapper-generator
# Note: the command is a single command + args. For a pipeline,
# set the command to: bash -c 'cmd1 | cmd2'
set -euo pipefail
CHECK="✓"
CROSS="✗"
LOG="/var/log/rsync.log"
LOCK_FILE="/run/lock/rsync.lock"
log() { echo "$(date '+%F %T') $*" >> "$LOG"; }
run() {
# SIGTERM at MAX_RUNTIME; SIGKILL KILL_GRACE later if ignored.
timeout -k 20s 5m rsync -a --delete /data/ /mnt/backup/data/
}
main() {
# Lock lives on the open descriptor; kernel frees it on exit.
exec 200>"$LOCK_FILE"
if ! flock -n 200; then
log "$CROSS previous run still active — skipping"
exit 0
fi
log "$CHECK lock acquired"
if run; then
log "$CHECK completed"
else
log "$CROSS failed"
exit 1
fi
}
main "$@"