How I read cron schedules without pretending I remember the syntax

Cron is simple once it is explained, but the syntax is not something I try to memorise perfectly.

A cron expression often looks like this:

0 2 * * *

If you do not read cron every day, that line is not obvious. The Crontab Generator helps build the expression, and Cron Next Runs helps check when it will actually run.

The simple idea

Cron runs commands on a schedule.

A crontab line usually looks like this:

<schedule> <command>

Example:

0 2 * * * /usr/local/bin/backup.sh

Plain meaning:

Run /usr/local/bin/backup.sh every day at 02:00.

The five cron fields

The schedule has five fields:

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

So this:

0 2 * * *

means:

minute:       0
hour:         2
day of month: every
month:        every
day of week:  every

In plain English:

Run at 02:00 every day.

Field 1: minute

The first field is minute, from 0 to 59.

Example:

15 * * * *

Plain meaning:

Run at minute 15 of every hour.

That means 00:15, 01:15, 02:15, and so on.

Field 2: hour

The second field is hour, from 0 to 23.

Example:

0 9 * * *

Plain meaning:

Run every day at 09:00.

Cron normally uses 24-hour time.

Field 3: day of month

The third field is the day number in the month.

Example:

0 9 1 * *

Plain meaning:

Run at 09:00 on the 1st day of every month.

Field 4: month

The fourth field is the month.

Example:

0 9 1 1 *

Plain meaning:

Run at 09:00 on January 1st.

Field 5: day of week

The fifth field is day of week.

Depending on the cron implementation, Sunday may be 0 or 7. This is why I like checking with a tool instead of relying only on memory.

Example:

0 9 * * 1

Plain meaning:

Run at 09:00 every Monday.

Common symbols

Cron uses a few symbols:

Examples:

*/5 * * * *

Every 5 minutes.

0 9,17 * * *

At 09:00 and 17:00 every day.

0 9 * * 1-5

At 09:00 Monday through Friday.

Step 1: describe the schedule in human words

Before writing cron, I write the sentence first.

Example:

Run every day at 2 AM.

Then I turn it into cron:

0 2 * * *

This prevents me from starting with symbols before I know what I want.

Step 2: build the expression

Open Crontab Generator and choose the schedule parts.

For a daily 2 AM job:

• minute: 0;
• hour: 2;
• day of month: every;
• month: every;
• day of week: every.

The result is:

0 2 * * *

Step 3: check the next run times

Before installing a job, open Cron Next Runs and paste the expression.

Check the next few run times. This catches mistakes like:

• running every minute instead of every hour;
• running at midnight instead of noon;
• using the wrong weekday;
• forgetting timezone assumptions.

If the next run list looks wrong, fix the expression before it reaches the server.

Step 4: add the command

A full crontab line includes the command:

0 2 * * * /usr/local/bin/backup.sh

Use absolute paths where possible. Cron does not always have the same environment as your interactive shell.

This can fail in cron:

0 2 * * * backup.sh

This is clearer:

0 2 * * * /usr/local/bin/backup.sh

Step 5: redirect output if needed

Cron may email output depending on the system. For scripts, I usually log output intentionally:

0 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Plain meaning:

• normal output goes to /var/log/backup.log;
• error output goes there too.

This makes failures easier to debug later.

Step 6: remember the environment is smaller

Cron jobs often fail because environment variables are missing.

Your terminal may know:

PATH
HOME
DATABASE_URL
NODE_ENV

Cron may not.

If a script depends on environment variables, define them in the script, load an env file, or configure them explicitly in the crontab.

My cron checklist

Before I save a cron job, I check:

1. Can I describe the schedule in plain English?
2. Did I build the expression from that sentence?
3. Did I check the next run times?
4. Is the command using absolute paths?
5. Does the script work when run manually?
6. Does the job need environment variables?
7. Where will output and errors go?
8. What timezone does the server use?

Cron is reliable when the schedule is clear. The hard part is making sure the five fields say what I think they say.