How to Write and Schedule Cron Jobs in Linux

Cron is a lightweight Linux scheduler used to run commands automatically at fixed times. It is useful for database backups, log rotation, certificate checks, report generation, and routine maintenance on RHEL, CentOS, Fedora, and other Unix-like systems.

A cron job can run as a normal user or as root, depending on which crontab contains it. The most dependable setups use a small shell script, absolute command paths, explicit logging, and a schedule that accounts for the server’s time zone.

Understand The Cron Schedule Format

A cron entry has five time fields followed by the command:

minute hour day-of-month month day-of-week command

For example, this job runs at 2:30 am every day:

30 2 * * * /usr/local/sbin/nightly-backup.sh

The asterisk means “every permitted value”. Ranges, lists, and steps are also available. 1-5 means Monday to Friday, 1,15 means the first and fifteenth, and */15 means every 15 minutes. A weekday report could therefore use:

15 8 * * 1-5 /usr/local/bin/send-report.sh

Cron also supports shortcuts such as @daily, @weekly, and @reboot. Traditional five-field syntax is usually clearer when a job needs careful timing. The Linux administration guides on command-line operations can help when checking permissions, services, and system configuration around scheduled tasks.

Create A Reliable Cron Script

Put complicated commands in a script rather than placing a long pipeline directly in the crontab. Set a predictable shell, use absolute paths, and stop when a command fails:

#!/usr/bin/env bash
set -euo pipefail

backup_dir="/var/backups/app"
mkdir -p "$backup_dir"
/usr/bin/pg_dump appdb > "$backup_dir/appdb-$(date +%F).sql"

Save the file as /usr/local/sbin/nightly-backup.sh and make it executable:

sudo install -o root -g root -m 0750 nightly-backup.sh /usr/local/sbin/nightly-backup.sh

Cron provides a much smaller environment than an interactive terminal. Define PATH when necessary, set SHELL=/bin/bash if Bash features are required, and avoid relying on aliases or variables from .bashrc. Credentials should come from protected files, a suitable secrets mechanism, or a service configuration—not from a world-readable crontab.

Install Jobs For The Right User

Run crontab -e to edit the current user’s schedule. Use sudo crontab -e only when the task genuinely needs root privileges. A user’s cron job cannot normally read root-owned files or restart protected services, while a root job has enough access to cause serious damage if its script is incorrect.

System-wide schedules can be placed in /etc/crontab or in files under /etc/cron.d/. These formats include an extra username field:

30 2 * * * backup /usr/local/sbin/nightly-backup.sh

On Fedora and modern RHEL systems, confirm that the scheduler is active with:

systemctl status crond
sudo systemctl enable --now crond

Use crontab -l to review an account’s current entries. Keeping job files under version control, with notes explaining their purpose and owner, makes handovers easier for an Australian team working across Sydney, Melbourne, or Brisbane.

Handle Time Zones And Australian Schedules

Cron follows the system clock, not necessarily the time shown on an administrator’s laptop. Check it with:

timedatectl
date

Australia has several time zones and daylight-saving rules. Sydney and Melbourne change between standard time and daylight time, while Brisbane does not observe daylight saving and Perth uses a different time zone altogether. A job scheduled for 2:00 am can therefore behave differently across hosts, and some local times may occur twice or be skipped during clock changes.

For a business that operates on Australian Eastern time, set the server’s time zone deliberately or document that cron uses UTC. Avoid scheduling critical work during the daylight-saving transition window. Public holidays also matter for payroll exports and customer reports, because a weekday cron expression does not know whether a date is an Australian public holiday.

Capture Output And Prevent Overlap

Cron can send output by email when a local mail transport agent is configured, but central logging is usually easier to operate. Redirect standard output and errors to a dated log:

15 1 * * * /usr/local/sbin/nightly-backup.sh >> /var/log/nightly-backup.log 2>&1

Use logger when messages should enter journald:

/usr/bin/logger -t nightly-backup "Backup completed successfully"

Long-running tasks may overlap if one execution has not finished before the next begins. flock provides a simple lock:

*/10 * * * * /usr/bin/flock -n /run/report.lock /usr/local/bin/send-report.sh

This is particularly useful for small businesses and Australian online retailers whose overnight jobs may compete with backups, imports, or payment reconciliation. If a task handles customer information, retain only the logs needed for operations and protect them under the organisation’s privacy and security obligations, including applicable requirements under Australia’s Privacy Act.

Test, Monitor, And Maintain Jobs

Test the script manually as the same user who will run it. For a root job, use a controlled command rather than immediately testing a destructive operation. Check recent cron messages with commands such as:

sudo journalctl -u crond --since "today"
sudo tail -n 50 /var/log/cron

The exact log file varies by distribution and logging configuration. Confirm that the expected output was created, permissions are correct, and failures produce a visible alert. A schedule that runs silently is difficult to trust.

Document the purpose, owner, expected runtime, dependencies, and recovery procedure. For teams coordinating infrastructure work, project planning tools can help track recurring maintenance alongside application changes. Review old jobs regularly, especially after moving workloads to Sydney or Melbourne cloud regions, changing database credentials, or replacing a server.

The key points are simple: use the correct crontab, write scripts with explicit paths and permissions, account for the server’s Australian time zone, prevent overlapping runs, and verify logs after deployment. A cron job is reliable when its timing, environment, ownership, and failure behaviour are all deliberate.