Cron FAQ

A cron job is a scheduled task on Unix-like systems (Linux, macOS) that runs a command or script automatically at a defined time or interval. The cron daemon (crond) checks every minute whether any job in the crontab is due and executes it. Typical uses: backups, log rotation, sending reports, clearing caches, and calling APIs on a schedule.

A cron expression is the short text pattern that tells a cron scheduler when to run a job. Standard cron expressions have five fields (minute, hour, day of month, month, day of week), for example 0 8 * * 1-5 for weekdays at 08:00. Some systems, like Quartz, extend this with a seconds field or a year field. Compose one visually with the Builder, or decode one with the Explainer.

A cron scheduler is the software that reads cron expressions and starts jobs at the matching times. On Linux this is the cron daemon (crond), but the term also covers schedulers built into other platforms, such as Quartz for Java, Kubernetes CronJobs, cloud schedulers like AWS EventBridge, and CI tools like Jenkins. They all share the same core idea: a cron expression decides when work runs.

Cron is the scheduler — the daemon that runs in the background. A crontab is the table (file) where schedules are stored, edited with the crontab command. A cron job is one entry in that table: a cron expression plus the command it should run.

Anything that has to happen on a schedule without a human pressing a button: nightly database backups, log rotation and cleanup, sending scheduled emails and reports, syncing data between systems, renewing certificates, health checks, and batch processing. If a task repeats at a predictable time, it is a candidate for a cron job.

From left to right: minute (0–59), hour (0–23), day of month (1–31), month (1–12), day of week (0–6, Sunday = 0). So 30 2 * * * means "every day at 02:30". Use the Builder to compose one visually.

The core set is: * (every value), , (a list, like 1,15), - (a range, like 9-17), and / (a step, like */10 for every 10th value). Extended dialects such as Quartz add ? (no specific value), L (last day), W (nearest weekday) and # (nth weekday of the month), but those are not supported by standard Unix cron.

Both. Standard cron accepts 0 and 7 for Sunday in the day-of-week field. 0 is the safest choice because every implementation supports it. Many implementations also accept names like SUN and MON.

Most cron implementations accept three-letter English names in the month and day-of-week fields, so 0 9 * * MON-FRI equals 0 9 * * 1-5. Names are case-insensitive, but numeric values remain the most portable choice across schedulers.

Standard Unix cron has minute-level resolution: five fields, no seconds. Schedulers like Quartz (used by many Java applications) use six or seven fields with seconds first, for example 0/30 * * * * ? for every 30 seconds. The Builder has a + Seconds toggle for composing 6-field Quartz-style expressions.

The question mark means "no specific value" and only exists in Quartz-style dialects. Quartz requires it in either the day-of-month or day-of-week field because it does not allow both to be restricted at once. In standard Unix cron the character is invalid; use * instead.

Standard cron treats them with OR logic: the job runs when either field matches. So 0 0 13 * 5 runs on the 13th of every month and on every Friday — not only on Friday the 13th. This is one of the most common cron surprises, and a good reason to preview a schedule with the Explainer before deploying it.

Use a step value in the minute field: */5 * * * *. The same pattern works elsewhere: 0 */2 * * * runs every 2 hours on the hour, and */15 9-17 * * 1-5 runs every 15 minutes during business hours on weekdays.

Put the minute and hour in the first two fields and leave the rest as asterisks. 0 8 * * * runs every day at 08:00, 30 23 * * * at 23:30. Remember cron uses 24-hour time in the server's local time zone.

Restrict the day-of-week field to 1-5 (Monday through Friday). 0 9 * * 1-5 runs at 09:00 on weekdays only. For weekends use 0,6 instead.

List both hours in the hour field: 0 6,18 * * * runs at 06:00 and 18:00. If the two runs are exactly 12 hours apart you can also write 0 */12 * * *. Lists work in every field, so the same idea covers twice a week or twice a month.

Standard cron has no "last day" symbol, because months end on the 28th through 31st. Common workarounds: schedule on 28-31 and let the script check whether tomorrow is the 1st, or use the L character if your scheduler is Quartz-based (0 0 L * ?). Running on the 1st at 00:05 instead is often the simplest reliable alternative.

They are shorthand strings most cron implementations accept in place of a full expression: @hourly = 0 * * * *, @daily (or @midnight) = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly (or @annually) = 0 0 1 1 *.

@reboot is special: it runs once when the system starts instead of on a time schedule.

Run crontab -e to open your user's crontab in an editor and crontab -l to list the jobs currently scheduled. Each line is one job: a cron expression followed by the command to run.

System-wide jobs also live in /etc/crontab and /etc/cron.d/.

Open the crontab with crontab -e and delete the job's line to remove it, or put a # at the start of the line to comment it out and disable it temporarily.

crontab -r removes your entire crontab at once — use it with care, because there is no undo.

By default cron runs in the system's local time zone. Some cron implementations honor a CRON_TZ or TZ variable at the top of the crontab to schedule in a different zone, and most cloud schedulers let you choose a zone explicitly. Servers are often set to UTC, so always check before assuming a job runs in your local time.

No. Cron jobs run with a minimal environment: your interactive shell's PATH, aliases and exported variables are not loaded. This is why a command that works in your terminal can fail in cron. Use absolute paths to binaries and files, or set PATH and other variables at the top of the crontab.

Cron mails a job's output to the crontab owner if a mail system is configured; otherwise output is lost unless you redirect it, for example command >> /var/log/myjob.log 2>&1.

The cron daemon's own activity is logged to /var/log/syslog (Debian/Ubuntu) or /var/log/cron (Red Hat), or is visible via journalctl -u cron on systemd systems.

macOS ships with cron, though Apple recommends launchd for new work. Windows has no cron; the native equivalent is Task Scheduler, or you can run real cron inside WSL. Cron expressions themselves are portable: many cross-platform tools, CI systems and cloud schedulers accept them on any operating system.

A cron expression generator is a tool that builds the expression for you: you choose the schedule in a visual interface (every 5 minutes, weekdays at 9, and so on) and the generator produces the matching cron syntax. Our free Builder is a cron expression generator that also shows a plain-English description and the next run times, so you can verify the schedule before using it.

Because cron syntax is compact and easy to get subtly wrong: swapped fields, the day-of-month/day-of-week OR rule, or a step that does not divide evenly. A crontab generator eliminates typos, and a good one previews the next run times so mistakes are visible before they reach production. Writing by hand is fine once you know the syntax — a generator is how you check yourself.

Mostly, with one caveat: dialects differ. Kubernetes CronJobs, Jenkins and GitHub Actions use standard 5-field expressions, so generator output works directly. Quartz and Spring's @Scheduled use 6 fields with seconds first — use the + Seconds toggle in our Builder for those. Always check whether your platform counts Sunday as 0 or 7 and whether it supports extended characters like L or #.

Paste it into a cron explainer and read the plain-English description back: if the words do not match your intent, the expression is wrong. Checking the next few computed run times catches off-by-one mistakes that a syntax check alone misses. Our Explainer does both — it parses the expression, describes every field, and lists the next five runs in your local time.

The usual suspects, in order: the command relies on PATH or environment variables that cron does not load (use absolute paths); the script is not executable or has Windows line endings; the schedule does not mean what you think it means (verify it with the Explainer); the cron daemon is not running; or output and errors are going to mail you never read. Redirect output to a log file first — it usually reveals the cause immediately.

When clocks jump forward, times inside the skipped hour simply do not occur that day; when clocks fall back, most modern cron implementations avoid running the job twice, but behavior varies. Jobs scheduled between 01:00 and 03:00 local time are at risk twice a year. Scheduling critical jobs outside that window, or running servers in UTC, avoids the problem entirely.

Cron happily starts a new run even if the previous one is still going. On Linux, wrap the command with flock (flock -n /tmp/myjob.lock command) so a second instance exits immediately, or implement a lock file inside the script. Alternatively, schedule less frequently than the job's worst-case duration.