Linux Crontab Scheduling: Automate Recurring Scripts and Cron Jobs

If you maintain servers, crontab is one of the small tools that quietly does a lot of work: it runs backups, log cleanup, and anything else you want on a clock. Some tasks only make sense when they repeat, and that gets harder when you are juggling more than one machine.

You solve that by declaring when the job runs—minute, hour, date, month, weekday—then the command or script cron should execute.

Below is the same flow I use when I teach this on a fresh box: open the editor, read the five fields, paste a line I trust, then prove it by hand before I walk away. If you recently finished a web stack and mostly need command lines, the Nginx on Ubuntu — install and firewall snippet is a tight companion to scheduled checks against that setup, and the full Nginx install walkthrough shows the surrounding context.

Open and edit your crontab

Open your terminal and run:

crontab -e

If you are using it for the first time, the system asks which editor to use.

You can use any editor; I reach for Vim (the second option here), but if you are newer on Linux, Nano (the first) is friendlier.

If the task must run as root—binding to a privileged port, touching root-only paths—use:

sudo crontab -e

Crontab syntax: the five schedule fields

Crontab lines follow a fixed pattern: five time fields, then the command.

Syntax

* * * * * <command-to-be-executed> <arguments>

Each star (or number) lines up with a slot on the clock.

Special symbols

1. * — every value in that slot
2. , — list of values (1,15 → 1 and 15)
3. - — inclusive range (1-5 → Monday–Friday in the weekday column, when your cron dialect maps that way)
4. / — step (*/15 in the minute column → every 15 minutes)

Practical crontab examples

Walk through these once with a harmless echo or touch before you wire a real backup.

Run a script every minute

* * * * * db_backup.sh

Run daily at midnight (00:00)

0 0 * * * db_backup.sh

Run every day at 5 am

0 5 * * * db_backup.sh

Run every Sunday at 5 am

0 5 * * SUN db_backup.sh

Same idea with a numeric weekday:

0 5 * * 0 db_backup.sh

Run on weekdays

* * * * 1-5 db_backup.sh

That line fires every minute Monday–Friday because the minute and hour fields are still *. If you meant “once each weekday,” narrow the first two fields—for example 0 9 * * 1-5 runs at 09:00 on weekdays.

You can also spell days:

* * * * MON-FRI db_backup.sh

Run on the first day of each month

0 0 1 * * db_backup.sh

Run on the first day of December each year

0 0 1 12 * db_backup.sh

Run every day at 10:50 am

50 10 * * * db_backup.sh

Run every 30 minutes

*/30 * * * * db_backup.sh

These patterns are the same ones I keep in a scratch file when I am tuning Linux task automation—once the mental model clicks, you are mostly rearranging numbers.

Cron schedule shortcuts

Some schedules have readable aliases:

1. @reboot — once at machine startup
2. @yearly / @annually — once a year
3. @monthly — once a month
4. @weekly — once a week
5. @daily — once a day
6. @midnight — same practical cadence as @daily on typical setups
7. @hourly — once an hour

Example

@reboot db_backup.sh

Manage cron jobs: list, remove, other users

1. List jobs for the current user:

crontab -l

2. Remove all jobs for that user (destructive—copy the file somewhere safe first):

crontab -r

3. Edit another user’s crontab when your permissions allow it:

crontab -u <username> -e

For repetitive Ubuntu or Nginx admin work, I still keep this single-page command snippet open in another tab—cron orchestrates when things run; that page is what to run once when you are building the box.

Frequently asked questions

What is the difference between crontab -e and sudo crontab -e?

crontab -e edits your user’s table. sudo crontab -e edits root’s table. They use different files, different identities at runtime, and often different permission outcomes—pick the one that matches how you would run the job manually.

What do the five fields in a crontab line mean?

In order: minute, hour, day of month, month, day of week, then the command. Asterisks mean “every,” commas list discrete values, hyphens express ranges, and slashes express steps.

How do I list or remove cron jobs for the current user?

Use crontab -l to print lines, crontab -r to wipe the whole table for that user, and crontab -u username -e when you are allowed to manage someone else’s entries.

Why might a cron job fail even when the schedule looks correct?

Cron inherits a small environment, so PATH, relative paths, permissions, and secrets behave differently than in your SSH session. Prefer absolute paths, log redirection, and a command you have already proven outside cron.

When should I use shortcuts like @daily instead of numbers?

Use @daily, @reboot, @hourly, and friends when they match your intent exactly—they are clear and harder to mistype. When you need a specific minute or an unusual rhythm, use the numeric fields.

That is the core of Linux crontab scheduling in day-to-day admin work. If anything misbehaves, capture logs, run the script as the same user cron uses, and compare sudo crontab -l with plain crontab -l so you are not debugging the wrong file. For more copy-paste maintenance around web servers, keep the Nginx Ubuntu command snippet handy—and if you want the narrative install I paired it with, read how to install and configure Nginx on your Linux server.

If you hit an edge case, tell me in the comments and we can narrow it down.