What Is a Cron Job? A Practical Beginner's Guide

How Cron works

Cron is a scheduler found on Unix-like systems. The Cron daemon reads schedules from crontab files and starts the associated command when the current date and time match an expression.

A standard entry contains five schedule fields followed by a command:

30 2 * * * /usr/local/bin/backup

This example starts a backup every day at 02:30.

A crontab entry can also redirect output, set environment variables or call a wrapper script. Keeping complex logic in a tested script usually makes the schedule easier to read and maintain.

Common uses

• Database backups and report generation
• Cache cleanup and log rotation
• Data imports and synchronisation
• Health checks and scheduled notifications

Safe setup checklist

Use absolute paths, define required environment variables, capture standard output and errors, and test the command under the same user that Cron will use. Prevent overlapping executions when a task can run longer than its interval.

User and system crontabs

Running crontab -e edits the current user's schedule. Commands run with that user's permissions and usually receive a smaller environment than an interactive terminal. System crontabs can include an additional username field, so copying an entry between the two formats without checking it can shift the command.

Common locations include /etc/crontab, /etc/cron.d and periodic directories such as /etc/cron.daily. Exact locations and service names vary by operating system.

Logging and troubleshooting

When a job works in a terminal but fails in Cron, check its user, working directory, PATH, shell and environment variables. Use absolute executable and file paths. Redirect standard output and standard error to a controlled log, or send them to the system logging service.

Also confirm that the Cron daemon is running and that the crontab was installed for the intended user. A timezone mismatch is a common explanation when a job runs successfully but at the wrong hour.

Make recurring jobs reliable

Design tasks to be safe when repeated. Use a lock when two copies must not overlap, return useful exit codes and alert on repeated failures. For backups, verify the output instead of assuming that a successful command created a usable recovery point. Store secrets outside the crontab and restrict access to any configuration files the job reads.

Paste an existing schedule into the Cron decoder, or create one with the Cron expression generator.

Cron, systemd and cloud schedulers

Cron is ideal for simple recurring tasks on a stable host. Systemd timers offer tighter service integration on Linux. Managed cloud schedulers are often better when jobs need retries, monitoring or high availability.