Skip to main content

Cron Q&A

Learning Focus

This page captures real Q&A sessions about cron — covering schedule syntax, crontab command options, operator logic, logging, and when to prefer systemd timers.

You

Tell me the logic of this cron, only on cron setup not path scripts: 0 9,17 * * 1-5 /usr/local/bin/office_task.sh >>/var/log/office_task.log 2>&1

ChatGPT

Here is the cron schedule logic only (ignoring the script path and logging part):

0 9,17 * * 1-5
│ │   │ │ │
│ │   │ │ └── Day of week: 1–5 (Monday to Friday)
│ │   │ └──── Month: every month
│ │   └────── Day of month: every day
│ └────────── Hour: 9 AM and 5 PM
└──────────── Minute: 0

What it means​

  • Minute: 0 — Runs at minute 00
  • Hour: 9,17 — Runs at 09:00 and 17:00
  • Day of month: * — Every day of the month
  • Month: * — Every month
  • Day of week: 1-5 — Monday through Friday

Final Meaning​

It runs:

At 09:00 and 17:00, every Monday through Friday, every month.

So basically:

  • Twice per weekday
  • Not on Saturday or Sunday

If you'd like, I can also explain how 1-5 maps to weekdays in cron.

You

That asterisk means "every", right? If the first * is not 0, does it mean every minute?

ChatGPT

Yes — exactly.

In cron, the asterisk * means:

"Every possible value for this field."

Cron format reminder​

*  *  *  *  *
│  │  │  │  │
│  │  │  │  └─ Day of week (0–7)
│  │  │  └──── Month (1–12)
│  │  └─────── Day of month (1–31)
│  └────────── Hour (0–23)
└───────────── Minute (0–59)

Your Question: If the first * (minute field) is not 0, does it mean every minute?​

Case 1:​

* 9 * * 1-5

This means:

  • * in minute — every minute
  • Hour = 9
  • Monday–Friday

So it runs every minute between 09:00 and 09:59, Monday–Friday.

That means: 09:00, 09:01, 09:02 … 09:59.

Case 2:​

0 9 * * 1-5

This means:

  • Minute = 0 (only once)
  • Hour = 9

So it runs only at 09:00, Monday–Friday.

Important Rule​

  • * = every value
  • A number = exact value
  • 1-5 = range
  • 9,17 = specific list
  • */5 = every 5 units

Example: Every minute​

* * * * *

Runs every minute of every hour of every day.

Example: Every 5 minutes​

*/5 * * * *

Runs at: 00, 05, 10, 15, 20, 25, etc.

So yes — if the first field is *, it means every minute within the allowed hour/day range.

You

Does / mean "every"? And does , create two conditions?

ChatGPT

Good question — and this is where many people get confused.

/ does NOT mean "every".​

It means:

"Step value" (run every X units).

What / Really Means​

Syntax:

*/X

Means: Every X units within that field.

Example 1 — Every 5 minutes​

*/5 * * * *
  • */5 in minute field — Every 5 minutes — 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55

Example 2 — Every 2 hours​

0 */2 * * *
  • Minute = 0
  • */2 in hour — Every 2 hours — 00:00, 02:00, 04:00, 06:00, etc.

Is / Two Conditions?​

Not exactly. It is one condition with a step.

For example:

*/5

Is actually shorthand for:

0-59/5

Meaning: From 0 to 59, step by 5.

So it's a range plus a step size — still one scheduling rule.

Important Difference​

SymbolMeaning
*Every value
,Specific values (list)
-Range
/Step value

Example Mixing Them​

1-10/2

Means: From 1 to 10, every 2 numbers — 1, 3, 5, 7, 9

Simple Answer​

  • / does NOT mean "every"
  • It means "every X units"
  • It is not two separate conditions — it is a range with a step
You

Thanks, I'm still missing the use of ,.

ChatGPT

Great — now we complete the cron puzzle.

, (Comma) in Cron​

The comma means:

"Also run at these specific values." It creates a list of exact values.

Example 1 — Multiple Hours​

0 9,17 * * *

Meaning:

  • Minute = 0
  • Hour = 9 and 17

Runs at: 09:00 and 17:00, every day.

So 9,17 = two exact hours.

Example 2 — Multiple Days of Week​

0 8 * * 1,3,5

Runs at 08:00 on Monday (1), Wednesday (3), and Friday (5).

Comma = specific selected values.

Example 3 — Mixed Numbers​

15 10 1,15 * *

Runs at 10:15 on the 1st and 15th of every month.

How It Differs from Others​

SymbolMeaningExampleResult
*Every value*Every unit
,Specific list1,5,9Only 1, 5, 9
-Range1-51,2,3,4,5
/Step*/5Every 5 units

Important: They Can Combine​

0 9-17/2 * * 1,3,5

Meaning:

  • Minute = 0
  • Hours from 9 to 17 every 2 hours — 9,11,13,15,17
  • Only Monday, Wednesday, Friday

Simple Mental Model​

  • * — everything
  • , — this AND this AND this
  • - — from X to Y
  • / — every X
You

How many , can we use? I saw your example had max 3.

ChatGPT

Good observation.

There is no fixed limit of 3 commas in cron.

You can use as many comma-separated values as you want, as long as:

  1. They are valid numbers for that field.
  2. They are within the allowed range.
  3. The whole cron line isn't excessively long (system limit, not comma limit).

General Rule​

Comma just means: "Run at value A OR value B OR value C OR …"

So this is perfectly valid:

0 1,3,5,7,9,11,13,15,17,19,21,23 * * *

That runs every odd hour.

Field Limits (Important)​

FieldAllowed Values
Minute0–59
Hour0–23
Day of Month1–31
Month1–12
Day of Week0–7 (0 and 7 = Sunday)

In the minute field, maximum distinct values you could list is 60 values (0–59).

Why I Used 3 in Example?​

Just for readability.

In real life:

  • If you use too many commas — it becomes messy.
  • Usually better to use range -, step /, or simplify logic.

Example: Bad vs Better​

Instead of:

0 9,10,11,12,13,14,15,16,17 * * *

Better:

0 9-17 * * *

Final Answer​

There is no small limit like 3. You can use many commas — limited only by valid values and line length.

You

Explain 1-5 in 0 9,17 * * 1-5 /usr/local/bin/office_task.sh >>/var/log/office_task.log 2>&1.

ChatGPT

Let's focus only on this part:

0 9,17 * * 1-5

The 1-5 is in the Day of Week field (the 5th field).

Cron structure reminder:

┌──────── minute (0–59)
│ ┌────── hour (0–23)
│ │ ┌──── day of month (1–31)
│ │ │ ┌── month (1–12)
│ │ │ │ ┌ day of week (0–7)
│ │ │ │ │
0 9,17 * * 1-5

What Does 1-5 Mean?​

1-5 means: From 1 to 5 inclusive.

In the day-of-week field, numbers mean:

NumberDay
0 or 7Sunday
1Monday
2Tuesday
3Wednesday
4Thursday
5Friday
6Saturday

So 1-5 means: Monday through Friday.

So Your Full Schedule Means:​

0 9,17 * * 1-5
  • Minute = 0
  • Hour = 9 and 17
  • Every day of month
  • Every month
  • Only Monday to Friday

Final Meaning​

It runs: At 09:00 and 17:00, Monday through Friday, every month.

  • Weekdays only
  • Not Saturday
  • Not Sunday

Why Use 1-5 Instead of 1,2,3,4,5?​

Because:

  • 1-5 is cleaner
  • Easier to read
  • Less error-prone
You

Field 1 = minutes, 2 = hours, 3 = days, 4 = month, 5 = days of the week — correct?

ChatGPT

Yes — that's correct.

Cron has 5 time fields (in this order):

*  *  *  *  *
│  │  │  │  │
│  │  │  │  └── 5. Day of week
│  │  │  └────── 4. Month
│  │  └───────── 3. Day of month
│  └──────────── 2. Hour
└─────────────── 1. Minute

Field Breakdown​

1. Minute​

Range: 0–59

0

At minute 00 only.

2. Hour​

Range: 0–23

9,17

At 09:00 and 17:00.

3. Day of Month​

Range: 1–31

15

On the 15th of the month.

4. Month​

Range: 1–12

1

January.

5. Day of Week​

Range: 0–7 (0 and 7 = Sunday)

1-5

Monday–Friday.

Your Example Applied​

0 9,17 * * 1-5
  • Minute — 0
  • Hour — 9 and 17
  • Day of month — every day
  • Month — every month
  • Day of week — Monday–Friday

Important Small Detail​

Field 3 (day of month) and Field 5 (day of week) have a special interaction rule in cron.

If you want, I can explain that clearly — it's one of the most common cron misunderstandings.

You

My knowledge says: run at 0 minute at 2 and at first day every month every week — 0 2 1 * * /usr/local/bin/monthly_report.sh >>/var/log/monthly_report.log 2>&1. Is that correct?

ChatGPT

Let's analyze the cron timing part:

0 2 1 * *

Break It Down by Field​

┌──────── minute (0–59)
│ ┌────── hour (0–23)
│ │ ┌──── day of month (1–31)
│ │ │ ┌── month (1–12)
│ │ │ │ ┌ day of week (0–7)
│ │ │ │ │
0 2 1 * *

1. Minute = 0 — At minute 00​

2. Hour = 2 — At 02:00 AM​

3. Day of Month = 1 — On the 1st day of the month​

4. Month = * — Every month​

5. Day of Week = * — Every day of the week​

Correct Meaning​

It runs: At 02:00 AM, on the 1st day of every month.

Important Correction​

You said: "run at 0 minute at 2 and at first day every month every week"

The "every week" part is not correct.

Because:

  • Day-of-week = *
  • Day-of-month = 1

When day-of-month is specific (1) and day-of-week is *, cron runs based on the 1st day of the month only. It does NOT mean weekly.

Simple Real-World Example​

  • Jan 1 — runs at 02:00
  • Jan 8 — does NOT run
  • Feb 1 — runs at 02:00
  • Mar 1 — runs at 02:00

So it is: a monthly job at 02:00 AM on the 1st of each month.

Quick Summary​

0 2 1 * *

= 02:00 AM on day 1 of every month.

You

crontab -e vs -l — what's the difference?

ChatGPT

Good — this is basic but very important.

crontab -e vs crontab -l​

They do different things.

crontab -e (edit)​

crontab -e

What it does:

  • Opens your user's crontab file
  • Lets you add, modify, or delete cron jobs
  • Opens in your default editor (nano, vim, etc.)

Example: You want to add:

0 2 1 * * /usr/local/bin/monthly_report.sh

You run crontab -e, add the line, save and exit. After saving — cron automatically installs it.

crontab -l (list)​

crontab -l

What it does:

  • Shows (prints) your current cron jobs
  • Does NOT open editor
  • Does NOT modify anything

Example output:

0 2 1 * * /usr/local/bin/monthly_report.sh
0 9,17 * * 1-5 /usr/local/bin/office_task.sh

Read-only view.

Quick Comparison​

CommandMeaningCan Modify?
crontab -eEdit crontabYes
crontab -lList crontabNo

Bonus (Useful)​

Remove all cron jobs:​

crontab -r

Warning: Dangerous — deletes everything.

Very Important Note​

These commands manage: your user's cron jobs.

If you use:

sudo crontab -e

You are editing root's crontab, not yours.

You

Does -r require confirmation?

ChatGPT

Short answer: usually NO — crontab -r does not ask for confirmation.

When you run:

crontab -r

It immediately deletes your entire crontab.

Same with:

sudo crontab -r

It deletes root's crontab immediately.

Why This Is Dangerous​

There is:

  • No "Are you sure?"
  • No undo
  • No recycle bin

Once deleted — it's gone.

Use:

crontab -i -r

The -i means interactive.

It will ask:

crontab: really delete user's crontab? (y/n)

Then you must type y.

Quick Summary​

CommandConfirmation?
crontab -rNo
crontab -i -rYes

Pro tip — good habit: Before deleting, always check your jobs first with crontab -l.

You

I have remembered -e, -l, -r — what else?

ChatGPT

Nice — you already know:

  • -e — edit
  • -l — list
  • -r — remove

Here are the other important crontab options you should know:

-i — Interactive (confirmation)​

Used with -r:

crontab -i -r

Asks before deleting.

-u — Specify user​

Used by root to manage another user's crontab.

sudo crontab -u john -l

Lists john's cron jobs.

sudo crontab -u john -e

Edits john's cron jobs.

Note: Normal users usually don't need this.

Install from file​

You can install a crontab from a file:

crontab mycronfile.txt

That replaces your current crontab with the file contents.

Very useful for:

  • Backups
  • Automation
  • Configuration management

Backup Your Crontab​

crontab -l > backup_cron.txt

Restore later:

crontab backup_cron.txt

Complete Quick List​

OptionMeaning
-eEdit
-lList
-rRemove
-iInteractive (confirm delete)
-u userManage specific user (root only)

That's basically everything 95% of admins use.

You

For crontab -l > backup_cron.txt, can we use stdin?

ChatGPT

Good question — now you're thinking like a real Linux user.

You asked: For crontab -l > backup_cron.txt, can we use stdin?

Short answer:

  • crontab -l — outputs to stdout
  • You redirect it using >
  • That is NOT stdin — it's stdout redirection.

What Happens Here​

crontab -l > backup_cron.txt
  • crontab -l prints to stdout
  • > redirects stdout to a file
  • So you save the output

This is output redirection, not stdin.

Where stdin Is Used​

crontab reads from stdin when you install a crontab.

Example:

cat backup_cron.txt | crontab -

Here crontab - means: Read from standard input.

So yes — stdin is used when installing, not listing.

Cleaner Way (No Pipe Needed)​

Instead of:

cat backup_cron.txt | crontab -

Better:

crontab backup_cron.txt

Even simpler.

Example Using Echo (stdin example)​

echo "0 2 * * * /script.sh" | crontab -

This sends the cron job directly via stdin.

Summary​

ActionUses stdout?Uses stdin?
crontab -lYesNo
crontab file.txtNoNo (reads file directly)
crontab -NoYes

So:

  • > — handles stdout
  • crontab - — reads from stdin
You

On crontab backup_cron.txt, how do I specify an absolute path?

ChatGPT

Good — this is simple but important.

When you run:

crontab backup_cron.txt

It reads the file from your current working directory.

If the file is somewhere else, you must give the absolute path.

Using Absolute Path​

Example:

crontab /home/rezriz/backup_cron.txt

That tells crontab exactly where the file is.

Another example:

crontab /root/cron/backups/monthly_cron.txt

Absolute path always starts with /.

How to Check Full Path​

If you're not sure where the file is:

realpath backup_cron.txt

or

pwd

Then combine:

crontab /full/path/to/backup_cron.txt

Important Note​

When restoring, this replaces your entire current crontab.

So before running:

crontab /full/path/file

It's good practice to check:

crontab -l

Example Full Workflow​

Backup:

crontab -l > /home/rezriz/cron_backup.txt

Restore:

crontab /home/rezriz/cron_backup.txt

That's it — just provide the full absolute path.

You

Do you agree that cron + systemd path + systemd timer = 100% controlling script automation in Linux?

ChatGPT

Short answer: Yes — combining cron + systemd service + systemd timer gives you very strong control over automation in Linux.

But not "100%" — more accurately:

Production-grade, modern, and fully controllable automation

Let me explain clearly.

1. Cron (Old School Scheduler)​

  • Simple
  • Works everywhere
  • Good for basic time-based jobs

But:

  • No dependency handling
  • No built-in retry logic
  • Weak logging (unless you manage it)
  • No easy status tracking

Cron is time-based only.

2. systemd Service (Execution Control)​

With systemd, you define:

  • User
  • Environment
  • Restart policy
  • Resource limits
  • Dependencies
  • Logging (journalctl)
  • Timeout rules

Example features:

Restart=on-failure
User=rezriz
WorkingDirectory=/home/rezriz/app

That's powerful control cron doesn't have.

3. systemd Timer (Modern Cron Replacement)​

A timer can replace cron completely.

Benefits over cron:

  • Missed jobs run after reboot (Persistent=true)
  • Random delay (RandomizedDelaySec=)
  • Dependency awareness
  • Integrated logging
  • Easy monitoring:
systemctl list-timers

Best Practice (Modern Linux)​

Instead of:

cron → script

Better:

systemd timer → systemd service → script

That gives:

  • Scheduling control
  • Execution control
  • Logging
  • Restart policy
  • Status visibility
  • Failure tracking

So Is It 100% Control?​

Almost.

You get:

  • Time-based scheduling
  • Boot-based triggers
  • Dependency triggers
  • Resource limits
  • Failure handling
  • Security control (User=, ProtectSystem=)

The only reason I wouldn't say "100%": automation can also involve at jobs, anacron, inotify triggers, event-driven systems, Kubernetes CronJobs, and CI/CD pipelines.

But for Linux server script automation?

Yes. Cron + systemd service + systemd timer = professional level control.

My Honest Recommendation​

If you're building serious automation:

  • Use systemd timer + service
  • Use cron only for legacy systems
You

Those 3 are enough, right?

ChatGPT

Yes — for a normal Linux server:

systemd service + systemd timer is already enough.

You actually don't need cron at all if you use systemd timers.

Minimum Modern Setup​

You only need:

  1. A script
  2. A systemd service file (how to run it)
  3. A systemd timer file (when to run it)

That's it. Cron becomes optional.

Why This Is Enough​

With just those 3, you get:

  • Scheduled execution
  • Logging (journalctl)
  • Auto-restart on failure
  • Run missed jobs after reboot
  • Run as specific user
  • Resource limits
  • Dependency control
  • Status monitoring

Example:

systemctl status myjob.service

You cannot do that cleanly with cron.

When Would You Still Use Cron?​

  • Very simple personal jobs
  • Old distributions
  • Containers without full systemd
  • Quick one-liners

But for serious automation? systemd timer + service is cleaner and more controllable.

Final Answer​

Yes — those 3 components are more than enough for professional-level Linux script automation.

You

About cron, there are no notifications or logs, right? What if we put it on the scripts?

ChatGPT

Good question.

Cron does have logging and notifications, but not in a "modern" way like systemd.

Let's break it clearly.

1. Does Cron Have Logs?​

Yes — but indirect.

Cron itself usually logs to:

  • /var/log/syslog (Debian/Ubuntu)
  • /var/log/cron (RHEL/CentOS)

Example:

grep CRON /var/log/syslog

But this only shows:

  • Job started
  • User
  • Command executed

It does NOT show full script output unless redirected.

2. Does Cron Send Notifications?​

Yes — via email (by default).

If your script outputs anything to stdout/stderr, cron tries to email it to the user who owns the crontab.

But:

  • Most servers don't have mail configured
  • So you never see the email

That's why many people think cron has no notifications.

3. What Happens When You Do This?​

0 2 * * * /script.sh >> /var/log/script.log 2>&1

This means:

  • >> — append stdout to file
  • 2>&1 — send stderr to same place

Now:

  • All output goes to a log file
  • No email is sent (because nothing reaches stdout/stderr)

So yes — you are manually handling logging.

4. Can You Add Notifications Inside Script?​

Absolutely — and this is common practice.

Inside the script you can add an exit code check:

#!/bin/bash

/usr/local/bin/do_something

if [ $? -ne 0 ]; then
    echo "Job failed" | mail -s "Cron Failure" admin@example.com
fi

Or send a Telegram message, Slack webhook, email, write to custom log, or push to a monitoring system.

So yes — you can fully control notifications inside the script.

5. Why systemd Feels Better​

With systemd:

journalctl -u myjob.service

You instantly see:

  • Output
  • Errors
  • Exit status
  • Restart attempts

Cron requires manual logging or mail setup.

Summary​

FeatureCronCron + Scriptsystemd
Basic schedulingYesYesYes
Built-in detailed logsNoManualYes
NotificationsEmail onlyCustomYes
Failure status trackingNoNoYes

Final Answer​

Cron alone — weak logging/notification. Cron + well-written script — very powerful.

So yes — if you put logging and notifications inside the script, you can make cron reliable.

But systemd gives you those controls natively.