Cron Job Descriptor & Crontab Expression Translator (2026)

Cron Schedule Architecture &
Crontab Expression Translation

Unix cron has governed system maintenance for half a century. Written initially by Brian Kernighan and expanded by Paul Vixie, cron operates as PID 1's quiet companion. It has no built-in retry mechanics, no dead-letter queue, and zero sentiment. Feed it a misplaced asterisk at 2 AM, and it will drop production tables with clinical efficiency.

Quick Answer: The POSIX 5-Field Standard Syntax

Standard POSIX crontab evaluates five whitespace-separated fields from left to right: Minute (0–59), Hour (0–23), Day of Month (1–31), Month (1–12), and Day of Week (0–7, where 0 and 7 both signify Sunday).

* * * * * command_to_execute
│ │ │ │ └── Day of week (0 - 7) (0 and 7 = Sunday)
│ │ │ └───── Month (1 - 12 or JAN - DEC)
│ │ └──────── Day of month (1 - 31)
│ └─────────── Hour (0 - 23)
└────────────── Minute (0 - 59)

Client-Side Privacy Guarantee

Server maintenance schedules and database backup scripts often reveal internal hostnames, S3 bucket names, and proprietary endpoints. Our translation engine runs 100% inside your local browser thread using pure JavaScript. Open Developer Tools (F12) and inspect the Network tab. When you input an expression, zero packets leave your machine.

1. The Anatomy of a POSIX Cron Expression

Every token in a crontab schedule governs a temporal dimension. Omitting or misconfiguring a single column completely alters your execution cycle. The five standard tokens accept distinct value ranges and formatting symbols:

Field Reference GuideSwipe horizontally →

Field Name	Allowed Values	Special Operators	Concrete Example
Minute	0–59	* , - /	*/15 (Runs every 15 mins)
Hour	0–23 (24h time)	* , - /	2,14 (Runs at 2 AM & 2 PM)
Day of Month	1–31	* , - / ? L W	1-5 (Runs 1st to 5th day)
Month	1–12 or JAN–DEC	* , - /	*/3 (Runs quarterly)
Day of Week	0–7 (0/7 = Sunday)	* , - / ? L #	1-5 (Monday through Friday)

The four syntax characters govern step and range behaviors:

Asterisk (*): The wildcard match. It matches all values in that specific field.
Comma (,): Value delimiter. Allows specifying discrete values such as 1,15,30.
Hyphen (-): Range operator. Defines an inclusive spectrum such as 9-17 (hours 9 through 17).
Slash (/): Step interval. Appended after a range or asterisk. For instance, */10 in the minute column executes every ten minutes, while 10-30/5 executes at minutes 10, 15, 20, 25, and 30.

2. Two Crontab Logic Traps That Break Production

Junior engineers regularly assume crontab operates on simple linear boolean logic. It does not. Standard Unix cron contains two historical quirks that trigger severe production incidents if misunderstood.

Trap 1: The Day-of-Month vs Day-of-Week OR Condition

In IEEE Std 1003.1 (POSIX), if both Day of Month and Day of Week are specified as non-wildcards (anything other than an asterisk), cron does not use an AND condition. It executes if either condition matches.

0 2 15 * 5 /usr/local/bin/payroll-run.sh

You might expect this to trigger only when the 15th of the month falls on a Friday. Instead, cron triggers on the 15th of every month AND on every Friday of the month. To restrict execution to the intersection of both dates, write the calendar verification inside your script:

0 2 15 * * [ $(date +\%u) -eq 5 ] && /usr/local/bin/payroll-run.sh

Trap 2: The Escaped Percent Sign (%) in Crontab Commands

In standard crontabs, the percent sign (%) is translated into a newline character before passing the command to the subshell. Everything following the unescaped % is fed into the command's standard input.

# BROKEN: Silently truncates at %Y and fails
0 0 * * * tar -czf /backups/data-$(date +%Y-%m-%d).tar.gz /var/www/html

The subshell receives tar -czf /backups/data-$(date + and crashes. To preserve percent signs, you must escape each one with a backslash:

# FIXED: Properly escaped date flags
0 0 * * * tar -czf /backups/data-$(date +\%Y-\%m-\%d).tar.gz /var/www/html

3. The Environment Trap: Why Scripts Fail in Crontab

Every systems administrator has experienced this headache: you test a shell script in your interactive terminal. It executes cleanly. You paste the exact command into your crontab. Nothing happens. No logs, no updates, zero trace.

The root cause is environment divergence. When you log into an SSH terminal, your shell reads /etc/profile, ~/.bash_profile, and ~/.bashrc. It loads your full PATH, aliases, Node version managers (NVM), and Python virtual environments.

Cron does none of that. It spawns a minimal, non-interactive subshell (frequently /bin/sh) with an austere default PATH:

PATH=/usr/bin:/bin

If your script relies on node, docker, aws-cli, or kubectl located in /usr/local/bin or ~/.nvm/versions/..., the subshell exits immediately with a command not found exit code 127.

Three Production Fixes for Missing Cron Paths

Declare Explicit PATH at Top of Crontab:Add this environment definition to line 1 of your crontab:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Use Full Binary Paths:Never write python3 main.py. Specify the absolute binary path:
/usr/bin/python3 /opt/services/analytics/main.py
Use an Explicit Wrapper Script:Wrap multi-step tasks in a dedicated bash script that explicitly sources your environment before running logic:
#!/usr/bin/env bash
set -euo pipefail
source /etc/environment
cd /opt/services/worker && /usr/local/bin/bundle exec rake sync:run

4. Hardening Crontab: Logging, Locks & Mail Spool

Deploying raw crontab jobs without defensive flags is a recipe for cascading outages. Three operational controls protect your hosts:

A. Standard Output & Error Redirection

When a cron command produces text, the daemon attempts to deliver it via the local MTA (like Postfix or Sendmail). If Sendmail is missing or unconfigured, local root mail spool boxes grow until they fill the filesystem. Append stdout and stderr explicitly:

0 3 * * * /opt/scripts/db-backup.sh >> /var/log/db-backup.log 2>&1

Tip: Pair every custom log file with a stanza in /etc/logrotate.d/ to prevent disk partition exhaustion.

B. Prevent Overlapping Runs with Flock Lockfiles

If an hourly database sync experiences network latency and takes 75 minutes to finish, cron will trigger a second instance while the first is still processing. This creates severe race conditions, duplicate API calls, and memory exhaustion. Use flock with non-blocking mode:

# -n exits immediately if lockfile is already held
0 * * * * flock -n /var/run/lock/sync.lock /opt/scripts/sync.sh >> /var/log/sync.log 2>&1

If running on lightweight containers (like Alpine Linux) where the util-linux flock package is not installed by default, use atomic directory creation in POSIX sh:

LOCKDIR="/var/lock/worker.lock"
if mkdir "$LOCKDIR" 2>/dev/null; then
  trap 'rmdir "$LOCKDIR"' EXIT
  /opt/scripts/sync.sh >> /var/log/sync.log 2>&1
else
  echo "Process already running. Exiting." >&2
  exit 1
fi

C. Silencing Unwanted Local Cron Mail

Stop cron from filling /var/mail/root with noisy execution summaries. Add an empty MAILTO variable directly in your crontab:

MAILTO=""
0 * * * * /opt/scripts/heartbeat.sh > /dev/null 2>&1

5. Modern Schedulers vs POSIX Crontab

Crontab was built for single-node mainframe computing. In cloud environments, running cron on an EC2 instance or virtual machine creates a single point of failure (SPOF). Modern engineering teams deploy cloud-native event bridges and container orchestrators:

Scheduler ComparisonSwipe horizontally →

Platform	Tokens	Timezone Engine	Concurrency & Retries	High Availability
Linux Crontab	5 fields	System clock only	None (Manual flock)	Single Host SPOF
AWS EventBridge	6 fields	Configurable time zones	Dead-Letter Queues (DLQ)	Serverless Multi-AZ
Kubernetes CronJob	5 fields	v1.27+ timeZone spec	concurrencyPolicy: Forbid	Cluster Pod Rescheduling
GCP Cloud Scheduler	5 fields	Explicit IANA timezone	Automatic retry backoff	Managed Regional/Global
Systemd Timers	Calendar specs	Host OS timezone	Persistent=true catch-up	Host daemon managed

The AWS EventBridge 6-Field Requirement

AWS EventBridge uses an extended format: cron(Minutes Hours Day-of-month Month Day-of-week Year). AWS introduces a strict rule: you cannot define wildcards for both Day-of-Month and Day-of-Week simultaneously. One of them must be a question mark (?).

# Valid AWS EventBridge Schedule: Runs 10 AM Mon-Fri in UTC
cron(0 10 ? * MON-FRI *)

Daylight Saving Time (DST) Hazards: Why UTC is Mandatory

Running server schedulers in local timezones is an operational disaster waiting to happen. Consider what takes place in US Eastern Time (America/New_York):

Spring Forward (Second Sunday of March): At 02:00 AM, the system clock jumps immediately to 03:00 AM. If you configured a daily backup or report for 0 2 * * *, the minute 02:00 literally never exists. Cron skips your job completely.
Fall Back (First Sunday of November): At 02:00 AM, the system clock rewinds to 01:00 AM. Any job configured between 01:00 AM and 01:59 AM executes twice, potentially causing double billing, duplicate notifications, or corrupted balance tables.

Anchor all production operating system clocks, database engines, and scheduling manifests to UTC. If a client requires execution aligned to business hours (e.g., 9:00 AM Wall Street time), calculate the UTC offset manually or leverage modern schedulers that natively accept IANA timezone declarations.

Kubernetes CronJob Spec: Concurrency & Deadlines

In Kubernetes, scheduling pods via the batch/v1 API requires explicit guardrails to prevent cluster node exhaustion:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: order-reconciliation
spec:
  schedule: "0 3 * * *"
  timeZone: "Etc/UTC"  # Supported in Kubernetes v1.27+
  concurrencyPolicy: Forbid  # Prevents concurrent pod execution
  startingDeadlineSeconds: 300  # Missed run tolerance window
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: worker
            image: registry.internal/billing:v2.4
            command: ["/bin/sh", "-c", "python process.py"]

Always set concurrencyPolicy: Forbid for state-modifying tasks. If an un-indexed database query slows down the pod, Kubernetes will refuse to launch the next scheduled run until the active pod completes or terminates.

Extended Modifiers: L, W, and # in Enterprise Cron Engines

While POSIX cron sticks to basic numbers and wildcards, advanced engines (like Quartz, Spring Framework, and Jenkins) support specialized calendar operators:

The "L" (Last) Modifier: In Day of Month, L means the last calendar day of the month (handles 28, 29, 30, or 31 automatically). In Day of Week, 5L means the last Friday of the month.
The "W" (Nearest Weekday) Modifier: Specifying 15W triggers on the nearest weekday (Mon-Fri) to the 15th. If the 15th is a Saturday, it triggers on Friday the 14th. If Sunday, it triggers on Monday the 16th.
The "#" (Nth Weekday) Modifier: Expresses ordinal occurrences. 2#1 means the first Monday of the month. 5#3 means the third Friday of the month.

Crontab Security Hardening & File Permissions

Misconfigured crontabs represent a frequent attack surface for Local Privilege Escalation (CWE-732). If a script run by root is world-writable, any unprivileged local user or compromised service can modify it and gain root execution within 60 seconds. Enforce these three security checks:

# 1. Verify target scripts are owned by root and writable only by root
chmod 750 /opt/scripts/*.sh
chown root:root /opt/scripts/*.sh

# 2. Restrict crontab command access using system allow lists
echo "root" > /etc/cron.allow
echo "deploy" >> /etc/cron.allow
rm -f /etc/cron.deny

# 3. Audit all drop-in cron directories for rogue executable files
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/

Systemd Timers: The Modern Alternative to Crontab

Modern enterprise Linux distributions (Ubuntu 20.04+, Debian 11+, RHEL 8+, Amazon Linux 2023) encourage replacing crontab entries with systemd timer units. A systemd timer separates the trigger schedule from the execution service, providing three distinct reliability benefits:

Persistent Catch-Up: With Persistent=true, if your host was powered down during the scheduled trigger, systemd executes the task immediately upon the next system boot.
Integrated Journal Logging: Output streams straight to journalctl -u db-backup.service with nanosecond timestamps, eliminating mail spool and file redirection bugs.
Hardware Resource Sandboxing: Restrict task memory with MemoryMax=512M and throttle CPU spikes via CPUQuota=30% directly in the service unit.

# File 1: /etc/systemd/system/db-backup.service
[Unit]
Description=Daily Database Backup Service
After=network.target

[Service]
Type=oneshot
User=backup
ExecStart=/opt/scripts/backup.sh

# File 2: /etc/systemd/system/db-backup.timer
[Unit]
Description=Trigger DB Backup Daily at 02:30 UTC

[Timer]
OnCalendar=*-*-* 02:30:00 UTC
Persistent=true

[Install]
WantedBy=timers.target

Enable and start the timer using systemctl daemon-reload && systemctl enable --now db-backup.timer. View all active timer triggers on the host with systemctl list-timers.

6. Master Reference: 12 Battle-Tested Cron Expressions

Instead of guessing token intervals, reference these proven configurations across production workloads:

Expression Reference TableSwipe horizontally →

Expression	Schedule Description	Common Use Case	Load Profile
* * * * *	Every minute	High-priority queue monitoring	High CPU/IO
/5 * * *	Every 5 minutes	Cache pre-warming, health pings	Moderate
/15 * * *	Every 15 minutes	Third-party API synchronization	Low-Moderate
0 * * * *	Top of every hour	Hourly usage rollups	Predictable
30 2 * * *	Daily at 02:30 AM	Database vacuum and pg_dump	Off-peak
0 8 * * 1-5	08:00 AM, Mon through Fri	Daily business digests	Standard
0 0 * * 0	Weekly at midnight Sunday	SSL renewal checks, log pruning	Off-peak
0 0 1 * *	1st day of every month	Monthly subscription billing	Heavy batch
0 0 1 1,4,7,10 *	Quarterly at midnight	Financial reporting closing	Heavy batch
@reboot	Once upon server boot	Spawning non-systemd background agents	Initialization
0 23 * * 5	Friday at 11:00 PM	Weekly full disaster recovery export	Weekend window
5,20,35,50 * * * *	Every 15 min, offset by 5	Prevents thundering herds at :00	Load balanced

7. Five-Step Crontab Incident Triage Protocol

When a scheduled task fails in production, follow this sequential debugging protocol rather than guessing:

Step 1: Verify the Cron Daemon HeartbeatConfirm the daemon service is actually active on the host. Run systemctl status cron (on Debian/Ubuntu) or systemctl status crond (on RHEL/CentOS). If inactive, start it:
sudo systemctl start cron
Step 2: Stream System Execution LogsCheck whether cron attempted invocation. If the log shows the command triggering, the problem is inside your script, not the daemon:
grep CRON /var/log/syslog | tail -n 50
Step 3: Simulate the Bare Cron EnvironmentRun your script in a stripped environment that mirrors cron's bare subshell:
env -i PATH=/usr/bin:/bin /bin/sh /path/to/script.sh
To inspect a running cron process's active environment variables:
cat /proc/$(pgrep cron)/environ | tr '\0' '\n'
Step 4: Check Permissions and Trailing NewlinesEnsure the target script has execution privileges (chmod +x /path/to/script.sh). Also confirm your crontab file ends with a blank trailing newline. Vixie cron ignores lines that lack an ending newline.
Step 5: Inspect Server Time Zone OffsetRun timedatectl. If your server is running in UTC but you expected local Eastern Time execution, your job is running 4 or 5 hours ahead of schedule. Modern Vixie and Debian cron support per-crontab timezone headers: prepend CRON_TZ=America/New_York at the top of the file to force cron to evaluate hours against your target timezone.

8. Connected Tooling & Infrastructure Automation

Scheduling is one piece of the infrastructure puzzle. Pair our translator with related client-side developer utilities:

Bash Script Builder

Generate defensive shell automation with strict error trapping, flock locks, and log rotation.

Docker Visualizer

Map multi-container task dependencies, volume mounts, and network topologies privately.

Base64 Encoder

Encode Kubernetes CronJob secret strings and environment tokens with zero network requests.

Explore our in-depth engineering architectural master guides for deeper technical specifications:

FACT-CHECKED & KERNEL SPEC AUDITED

Marcus Vance

Senior Site Reliability Engineer & Linux Systems Auditor. Specializes in multi-region orchestration, POSIX compliance, and serverless event architecture.

Audited against IEEE Std 1003.1-2017 (POSIX) and AWS EventBridge Scheduler Specifications for 2026.

Crontab & Scheduling FAQ Matrix

What does each field represent in a standard 5-part crontab expression?

A standard POSIX crontab string contains five whitespace-separated tokens: Minute (0–59), Hour (0–23 in 24-hour time), Day of the Month (1–31), Month of the Year (1–12 or JAN–DEC), and Day of the Week (0–7, where both 0 and 7 represent Sunday, or SUN–SAT). Every field accepts wildcards, step intervals, ranges, and comma-delimited lists.

What happens if I set both Day of Month and Day of Week in crontab?

POSIX cron treats these two fields with an OR condition, not an AND condition. If you configure '0 2 1,15 * 1', the daemon executes on the 1st of the month, on the 15th of the month, AND on every Monday, regardless of the calendar date. If you need a task to trigger strictly when the 1st falls on a Monday, you must write a date check inside your shell script.

Why does my script work in interactive bash but fail when run by cron?

Cron executes commands in a bare, non-interactive shell (usually /bin/sh) without sourcing ~/.bashrc, ~/.bash_profile, or /etc/profile. As a result, environment variables like PATH, NVM_BIN, or custom virtualenv paths are completely absent. The default crontab PATH is typically just /usr/bin:/bin. To fix this, define full binary paths (such as /usr/local/bin/node) or export your custom PATH at the top of your crontab file.

Why do unescaped percent signs (%) break crontab commands?

In Vixie and standard Unix cron daemons, the percent character (%) represents a newline unless escaped with a backslash. The daemon passes text before the first unescaped % to the shell, and routes everything after the % to the script as standard input. If you run a command like 'date +%Y-%m-%d', cron truncates the command and throws an error. You must write 'date +\%Y-\%m-\%d'.

How does AWS EventBridge 6-part cron syntax differ from POSIX crontab?

AWS EventBridge uses a 6-field pattern: (Minutes Hours Day-of-month Month Day-of-week Year). AWS strictly forbids specifying both Day-of-Month and Day-of-Week simultaneously. One of those two fields must be a question mark (?) wildcard to declare 'no specific value'. Furthermore, Day-of-Week uses 1 for Sunday and 7 for Saturday, unlike Linux cron which accepts 0 and 7 for Sunday.

How do I prevent overlapping execution when a cron job takes longer than its schedule interval?

Wrap your cron script invocation with the Linux 'flock' utility using non-blocking mode: 'flock -n /var/run/lock/task.lock /opt/scripts/sync.sh'. If a prior instance of the script is still running and holds the file lock, flock exits immediately with a return code of 1, preventing runaway process queues, thread exhaustion, and database deadlocks.

Does crontab run missed jobs if the server was offline or asleep?

No. Standard Unix cron is a real-time event loop. If your machine is suspended, powered off, or experiencing kernel panic during the scheduled trigger minute, cron skips that run permanently. If you require catch-up execution after downtime, use anacron on desktop machines or systemd timers with the 'Persistent=true' directive on production servers.

How does Daylight Saving Time (DST) affect scheduled cron tasks?

If your system clock runs in local time (such as US Eastern or Central), spring forward transitions skip the 2:00 AM to 3:00 AM hour completely, causing any jobs scheduled in that window to never run. During autumn fall back transitions, jobs scheduled between 1:00 AM and 2:00 AM trigger twice. For production infrastructure, always anchor server clocks and crontab schedules to UTC.

How can I redirect stdout and stderr to a log file without creating huge disk bloat?

Append standard output and standard error using redirection operators: '>> /var/log/myjob.log 2>&1'. To prevent infinite log growth from filling your root partition, register the log file in /etc/logrotate.d/ with daily rotation, gzip compression, and a retention limit of 7 to 14 days.

What does MAILTO="" do at the top of a crontab file?

By default, whenever a scheduled cron task prints output to stdout or stderr, the cron daemon attempts to email that text to the local system user via sendmail. Setting 'MAILTO=""' at the beginning of the crontab disables this behavior entirely, stopping discarded mail spools from clogging /var/mail/ or spamming local system logs.

How do Kubernetes CronJobs handle concurrent job runs?

Kubernetes CronJob specifications provide a 'concurrencyPolicy' field with three modes: 'Allow' (default, jobs run concurrently even if previous pods are active), 'Forbid' (skips starting a new pod if the previous one is still executing), and 'Replace' (terminates the currently running pod and replaces it with a fresh container). Production batch pipelines should almost always specify 'Forbid'.

What is the difference between /5 * * * and 5 * * * *?

'*/5 * * * *' executes every 5 minutes across every hour of the day (at minute 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55). In contrast, '5 * * * *' executes exactly once per hour, specifically when the clock hits minute 5 (e.g., 1:05, 2:05, 3:05).

Can crontab execute tasks with second-level precision?

Standard POSIX crontab operates at a 60-second minimum granularity. It cannot evaluate seconds. If you need sub-minute scheduling, use Quartz scheduler (which includes a 6th leading field for seconds), Spring @Scheduled annotations, systemd timers with 'AccuracySec=1us', or a persistent daemon loop paired with sleep intervals.

What are crontab predefined special strings like @reboot and @daily?

Predefined shortcuts replace standard 5-token strings in modern daemons. '@reboot' runs once immediately after the cron daemon initializes at system boot. '@yearly' and '@annually' map to '0 0 1 1 *'. '@monthly' maps to '0 0 1 * *'. '@weekly' maps to '0 0 * * 0'. '@daily' and '@midnight' map to '0 0 * * *'. '@hourly' maps to '0 * * * *'.

How do I audit crontab execution history on a Linux server?

On Ubuntu and Debian systems, inspect syslog by running 'grep CRON /var/log/syslog'. On Red Hat, Rocky Linux, or Amazon Linux systems, review '/var/log/cron'. If your host uses systemd-journald, execute 'journalctl -u cron -e' to stream the latest daemon trigger events and command exit statuses.

How do I run a cron job as a specific non-root user?

As root, you can edit another user's personal crontab by passing the user flag: 'crontab -u deploy -e'. Alternatively, if you write schedules directly into the system-wide '/etc/crontab' file or under '/etc/cron.d/', you must supply a 6th field between the day-of-week and the shell command specifying the exact username to execute under.