The ultimate Linux crontab guide: syntax, examples, and troubleshooting

Crontab is a Linux configuration file used to schedule commands or scripts to run automatically at specific times. In simple terms, crontab Linux automation helps you run repetitive tasks like backups, log cleanup, reports, updates, and maintenance jobs without doing them manually.

If you have ever had to run the same command every day, every hour, or every few minutes, a Linux cron job is the simplest fix. You define the schedule once, and Linux handles the rest. If you only need to build or check an expression quickly, try our crontab generator before editing production cron jobs.

Before going deeper, it helps to understand three important terms:

Cron job: The actual task or command you want to run.
Crontab: The table or file where scheduled tasks are configured.
Cron daemon: The background system service that checks the crontab and runs jobs at the correct time.

By the end of this guide, you will understand crontab syntax, real crontab examples, how to run a cron job every 5 minutes, and how to fix a crontab not working issue.

Getting started with the crontab command in Linux

The crontab command in Linux lets you safely list, edit, and remove scheduled cron jobs for a user. You usually do not edit cron files manually. Instead, you use the crontab command so Linux can install and manage the schedule correctly.

How to list cron jobs

To check your current user’s cron jobs, run:

crontab -l

This command answers the common question: how to list cron jobs in Linux?

If you have no active cron jobs, you may see a message like:

no crontab for username

That simply means no cron schedule has been created for your current user yet.

How to edit cron jobs

To create or edit your cron jobs, run:

crontab -e

The first time you use this command, Linux may ask you to choose a default editor. Beginners usually find Nano easier than Vim.

If Nano opens, you can edit the file, then save it with:

CTRL + O
ENTER
CTRL + X

Each line in the crontab file usually represents one scheduled job.

How to remove cron jobs

To remove all cron jobs for your current user, run:

crontab -r

Be careful. This command instantly deletes your entire crontab file without opening an editor.

A safer option is:

crontab -i

The -i flag asks for confirmation before deleting your cron jobs.

Decoding crontab syntax and expressions

Understanding crontab syntax is the part that prevents most mistakes. You can write expressions by hand here, or use the crontab generator when you want a quick sanity check.

A standard cron expression has five time fields followed by the command you want to run:

* * * * * /path/to/command
│ │ │ │ │
│ │ │ │ └── Day of the week
│ │ │ └──── Month
│ │ └────── Day of the month
│ └──────── Hour
└────────── Minute

So, the structure is:

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

The 5 time fields breakdown

Field	Allowed Values	Meaning
Minute	`0-59`	The minute when the job runs
Hour	`0-23`	The hour of the day
Day of month	`1-31`	The calendar day
Month	`1-12`	The month of the year
Day of week	`0-6` or `0-7`	The weekday, where Sunday is `0` or `7`

Example:

30 14 * * * /home/user/backup.sh

This runs /home/user/backup.sh every day at 2:30 PM.

Special cron operators

Cron expressions become powerful because of special operators.

Operator	Example	Meaning
`*`	`* * * * *`	Every possible value
`,`	`1,15,30 * * * *`	Multiple specific values
`-`	`1-5 * * * *`	A range of values
`/`	`/5 * * *`	Step value or interval

For example:

*/10 * * * * /path/to/script.sh

This runs the script every 10 minutes.

Another example:

0 9-17 * * 1-5 /path/to/script.sh

This runs the script every hour from 9 AM to 5 PM, Monday through Friday.

Time-saving crontab shortcuts

Crontab also supports shortcuts that make common schedules easier to read.

Shortcut	Meaning
`@hourly`	Runs once every hour
`@daily`	Runs once every day
`@weekly`	Runs once every week
`@monthly`	Runs once every month
`@yearly`	Runs once every year
`@reboot`	Runs once when the system starts

Example using the popular crontab reboot tag:

@reboot /home/user/startup-script.sh

This runs the script automatically after the system boots.

Practical crontab examples and common intervals

The best way to learn cron is through real crontab examples. Below are common schedules you can copy and adjust for your own scripts.

Interval Examples

Goal	Cron Expression
Cron job every 5 minutes	`/5 * * * /path/to/script.sh`
Crontab every hour	`0 * * * * /path/to/script.sh`
Cron schedule daily at midnight	`0 0 * * * /path/to/script.sh`
Every day at 6 AM	`0 6 * * * /path/to/script.sh`
Every Sunday at midnight	`0 0 * * 0 /path/to/script.sh`
Every weekday at 5 PM	`0 17 * * 1-5 /path/to/script.sh`
First day of every month	`0 0 1 * * /path/to/script.sh`
Every 15 minutes	`/15 * * * /path/to/script.sh`

Cron Job Every 5 Minutes

A very common question is: how do I run a cron job every 5 minutes?

Use:

*/5 * * * * /path/to/script.sh

This tells cron to run the script every 5 minutes, every hour, every day.

Crontab Every Hour

To run a task once every hour, use:

0 * * * * /path/to/script.sh

This runs the job at minute 0 of every hour.

Examples:

1:00
2:00
3:00
4:00

Cron Schedule Daily

To run a job once per day at midnight, use:

0 0 * * * /path/to/script.sh

This is useful for daily backups, cleanup tasks, reports, and database exports.

Every Weekday at 5 PM

To run a task Monday through Friday at 5 PM, use:

0 17 * * 1-5 /path/to/script.sh

This is useful for end-of-day reports, workday notifications, or weekday-only maintenance tasks.

Why is my crontab not working? Troubleshooting guide

One of the most searched cron questions is: why is my crontab not working?

The frustrating part is that cron can fail silently. Your command may work perfectly in the terminal but fail when cron runs it automatically. The most common reasons are missing environment variables, wrong paths, permission issues, and hidden errors.

Issue 1: missing crontab environment variables

Cron runs commands in a limited shell environment. That means it may not have the same PATH, variables, aliases, or user settings you have in your normal terminal session.

For example, this may work in your terminal:

python3 /home/user/scripts/report.py

But fail in cron because cron cannot find python3.

A safer cron job uses the full path:

/usr/bin/python3 /home/user/scripts/report.py

You can find the full path of a command with:

which python3

Example result:

/usr/bin/python3

Then use that absolute path in your crontab:

*/5 * * * * /usr/bin/python3 /home/user/scripts/report.py

You can also define environment variables at the top of your crontab:

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Issue 2: where are crontab logs?

Another common question is: where are crontab logs stored?

Cron logs depend on your Linux distribution.

For Ubuntu and Debian, check:

/var/log/syslog

You can search cron activity with:

grep CRON /var/log/syslog

For CentOS, RHEL, and Fedora, check:

/var/log/cron

You can view recent cron logs with:

tail -f /var/log/cron

These logs help you confirm whether cron attempted to run your command.

Important: system cron logs usually show that a job started, but they may not show the full error output from your script. That is why custom logging is so useful.

Issue 3: permission denied

If cron tries to run a script but the script is not executable, the job may fail with a permission error.

Make your script executable with:

chmod +x /path/to/script.sh

Then test it manually:

/path/to/script.sh

If the script fails when you run it manually, cron will not fix it. Always test the command directly before adding it to crontab.

Best practice: redirect output to a custom log file

To catch errors early, redirect both normal output and error output to a log file:

*/5 * * * * /path/to/script.sh >> /var/log/myjob.log 2>and1

Here is what it means:

>> /var/log/myjob.log appends standard output to the log file.
2>and1 sends error output to the same place.

If you do not have permission to write to /var/log, use a log file inside your home directory:

*/5 * * * * /path/to/script.sh >> /home/user/myjob.log 2>and1

This makes troubleshooting much easier because you can inspect exactly what your script printed or failed on.

Crontab best practices

A reliable Linux cron job should be easy to read, easy to debug, and safe to run repeatedly.

Here are a few best practices:

Use absolute paths

Avoid this:

python3 script.py

Use this instead:

/usr/bin/python3 /home/user/scripts/script.py

Absolute paths reduce the chance of cron failing because of missing environment variables.

Add logging to important jobs

For production tasks, never let cron fail silently.

Use:

0 0 * * * /home/user/backup.sh >> /home/user/backup.log 2>and1

This gives you a clear place to check when something goes wrong.

Avoid overlapping jobs

If a cron job runs every 5 minutes but sometimes takes 10 minutes to finish, multiple copies may run at the same time.

For important scripts, consider using a lock file or a tool like flock:

*/5 * * * * flock -n /tmp/myjob.lock /path/to/script.sh

This helps prevent duplicate jobs from running together.

Test before scheduling

Before adding a command to crontab, run it manually:

/path/to/script.sh

Then test it with the same shell and paths cron will use.

Best Claude Skills for Developers: Claude Code Skills Worth Installing, Studying, or Building - if you automate repeated developer workflows with cron, this guide shows how the same repeatable tasks can become Claude Skills for coding, testing, review, DevOps, and security.
How to create Skills for Claude: a developer guide to SKILL.md and Claude Code - useful if your cron workflow has grown into a reusable agent skill with a clear SKILL.md, triggers, and safe tool permissions.
What is OpenClaw (formerly Clawd AI, Moltbot)? - a related local-first AI workflow to compare with cron jobs, shell scripts, and project-level automation.
Docker tricks for 2026 - pairs well with cron when you schedule container cleanup, backups, health checks, or maintenance scripts.
Crontab generator - use this internal tool to create or verify cron expressions before adding them to crontab -e.

Summary checklist for a reliable cron job

Before deploying your next cron job, use this quick checklist:

Confirm your crontab syntax with our crontab generator or a tool like Crontab.guru.
Use absolute paths for commands, scripts, and files.
Make sure your script is executable with chmod +x.
Redirect output to a custom log file using >> logfile 2>and1.

Crontab is one of the simplest and most powerful automation tools in Linux. Once you understand the relationship between a Linux cron job, the crontab file, and the cron daemon, you can automate repetitive tasks with confidence.

Whether you need a cron job every 5 minutes, a crontab every hour, or a cron schedule daily, the same core syntax applies. And when your crontab is not working, checking environment variables, logs, permissions, and output redirection will usually lead you to the fix.