Get started with Linux cron jobs

Write crontab schedules, control the execution environment, capture output, and detect jobs that fail or never finish.

Guance Editorial Team 2026-10-27 3 min read Updated 2026-10-27

Cron runs commands on a schedule. Edit your user's task table with crontab -e, then give each command five time fields: minute, hour, day of month, month, and day of week.

The most common operational surprise is the execution environment. A command that works in an interactive shell can fail under cron because its PATH, working directory, credentials, or environment variables differ.

Read the five time fields

minute  hour  day-of-month  month  day-of-week  command
0–59    0–23  1–31          1–12   0–6          ...
                                 0 = Sunday

Common Vixie/Cronie implementations also accept 7 for Sunday.

# Every ten minutes.
*/10 * * * * /opt/jobs/heartbeat.sh

# Daily at 03:30.
30 3 * * * /opt/jobs/backup.sh

# Weekdays at 09:00.
0 9 * * 1-5 /opt/jobs/report.sh

Supported shortcuts commonly include @daily, @hourly, and @reboot. The last means daemon-startup scheduling rather than a portable promise of one run at every machine boot; check the implementation.

Manage the task table

crontab -e    # Edit the current user's table.
crontab -l    # List it.
crontab -r    # Remove it; commonly no confirmation prompt.

Use the removal command only when you intend to delete the whole user table. System entries in /etc/cron.d/ include an additional username field; do not copy that field into a personal crontab.

When both day-of-month and day-of-week are restricted, common Vixie/Cronie implementations match either field. Also check time zones, daylight-saving transitions, and whether one run can overlap the next. Put comments on separate lines; a percent sign inside the command normally needs escaping because cron assigns it special meaning.

Make the environment explicit

Do not assume cron sources .bashrc or inherits an interactive SSH Agent. Its default PATH varies by implementation and configuration.

Use full executable paths, such as /usr/bin/pg_dump.
Set a deliberate PATH or load a controlled environment file inside the script.
Use explicit file paths and set the working directory when necessary.

A deliberately stripped environment can expose hidden dependencies:

env -i /bin/sh -c '/absolute/path/to/your-command'

This is a useful diagnostic approximation, not an exact reproduction of cron's environment or task-account permissions. Test under the actual task account too.

Capture output and completion

30 3 * * * /opt/jobs/backup.sh >> /var/log/backup.log 2>&1

The task account must be able to open the log. Cron can mail unredirected output through a local mail system, but that is only useful if the MTA, MAILTO, and delivery path work.

For important jobs, record a task name, run ID, start time, finish time, and exit code. That makes it possible to distinguish a task that never started from one that failed or is still running. With DataKit log collection, test both start and completion records, then choose a detection window that allows for the task's normal duration and collection delay.

FAQ

When should I use a systemd timer?

Cron is simple and broadly available. A systemd timer can integrate with service dependencies and the journal. Retry behavior belongs in the service or task configuration; the timer does not automatically guarantee it. Use the mechanism that fits the host and required lifecycle controls.

The task ran but had no effect. Where should I look?

Check the task's own output, permissions, working directory, and environment. Inspect the cron service's journal or configured syslog destination for evidence that the command was launched.

How do I prevent overlapping runs?

Use a locking primitive such as flock, with a pre-created lock directory controlled by the task account. A separate “does the lock file exist?” check has a race. A host-local lock does not coordinate independent machines.

References: crontab syntax, systemd timers.