1. The 5-Field Standard Crontab Architecture
The standard Unix cron daemon, originally written by Ken Thompson and later standardized across Vixie Cron and POSIX, schedules repetitive automated background tasks. A standard cron expression consists of five space-separated fields:
┌───────────── Minute (0 - 59) │ ┌───────────── Hour (0 - 23) │ │ ┌───────────── Day of Month (1 - 31) │ │ │ ┌───────────── Month (1 - 12 or JAN - DEC) │ │ │ │ ┌───────────── Day of Week (0 - 6, where 0 is Sunday, or SUN - SAT) │ │ │ │ │ * * * * *
*)Represents "every" unit of time. For example, * in the Minute field means "execute every minute".
/)Specifies step increments. */15 in the Minute field executes at minute 0, 15, 30, and 45.
-)Defines a continuous range. 1-5 in the Day-of-Week field schedules jobs Monday through Friday.
,)Specifies discrete values. 1,15 in the Day-of-Month field executes on the 1st and 15th of the month.
2. Standard 5-Field Cron vs. 6-Field Extended Cron (Quartz & AWS)
A frequent point of confusion among engineers is the difference between standard POSIX cron and cloud scheduler formats:
- Standard Linux & Kubernetes CronJob: Uses 5 fields (Minute, Hour, Day, Month, Day-of-Week). Does not support second-level precision.
- AWS EventBridge / CloudWatch Rules: Uses 6 fields (Minutes, Hours, Day-of-month, Month, Day-of-week, Year). Requires a
?(wildcard) in either Day-of-Month or Day-of-Week. - Spring / Quartz Scheduler: Uses 6 or 7 fields with a leading Seconds field (Seconds, Minutes, Hours, Day, Month, Day-of-Week, Year).
3. Popular Crontab Presets and Cheatsheet
Our tool includes convenient one-click presets for common automation frequencies:
* * * * *Every minute: Useful for high-frequency queue consumers or health polling checks.
0 * * * *Every hour: Executes at minute 0 of every hour (e.g. 1:00, 2:00, 3:00).
0 0 * * *Daily at midnight: Perfect for database backups, log rotation, and SSL certificate expiration checks.
0 0 * * 0Weekly on Sunday: Scheduled weekly batch reports and cleanup routines.
0 0 1 * *Monthly on the 1st: Monthly billing jobs and database vacuum operations.
4. Why Production Cron Jobs Fail (The Top 4 Silent Bugs)
- The Missing PATH Environment: The cron daemon executes in a severely restricted environment where
PATH=/usr/bin:/bin. Commands relying on/usr/local/bin,node, orkubectlwill silently fail unless full absolute paths are specified. - Timezone Misunderstandings: Linux servers typically run in UTC. Scheduling a job at
0 2 * * *intending 2:00 AM local time will run at an unexpected hour if the server timezone is UTC! - Overlap & Thundering Herd: If a job scheduled to run every 5 minutes takes 7 minutes to complete, concurrent executions can exhaust database connection pools. Always use lock wrappers like
flock -n /var/lock/myjob.lock /path/to/script.sh. - Silent Failures: By default, cron emails output to the local root mail spool. If no MTA is configured, errors disappear into the void. Always redirect stderr:
>> /var/log/myjob.log 2>&1.
5. Kubernetes CronJob Manifest Example
apiVersion: batch/v1
kind: CronJob
metadata:
name: database-backup-nightly
spec:
schedule: "0 2 * * *" # Runs every night at 2:00 AM UTC
concurrencyPolicy: Forbid
successfulJobsHistoryLimit: 3
failedJobsHistoryLimit: 1
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: postgres:16-alpine
command: ["/bin/sh", "-c", "pg_dump -h db -U postgres mydb | gzip > /backup/mydb.sql.gz"]
restartPolicy: OnFailure