PTENES
MODULE 4.4

⏰ Cron: Automated Tasks

Cron is the server’s programmable alarm clock. You say, "every day at 3 a.m., make a backup," and the server does it on its own, forever. Here you’ll learn to schedule tasks that run without you needing to be there.

6
Topics
45
Minutes
Basic
Level
Hands-on
Type
1

What Is Cron

O cron is a program that comes preinstalled on every Linux server. Its job is simple: watch the clock and, at the right time, run the commands you scheduled. You write the task once, and it repeats on its own forever, without you needing to open the terminal again.

CRON: A DAY ON THE SERVER, MAPPED OUT cron 00h 06h 12h 23h backup 03h 04:00 cleanup 9 a.m. report check every 5 min

🧠 Analogy: The Programmable Alarm Clock

Think of cron as your phone's alarm clock, only much more powerful. On an alarm clock, you set a time and an action: "7 a.m., play the music." In cron, you set a time and a command: "3 a.m., run the backup."

  • •The alarm goes off every day at the same time, even if you’re not watching.
  • •Cron run the command every day at the scheduled time, even if no one is logged in to the server.
  • •The difference: an alarm clock makes noise; cron does work (backup, cleanup, email sending).

💡 Why cron is so widely used

Every task that needs if it repeats over time and a candidate to become a cron job: database backup, temporary file cleanup, certificate renewal, report delivery, checking which sites are online. Instead of remembering to do this manually (and forgetting half the time), cron does it on autopilot. Each scheduled task is called a cron job.

2

Crontab Syntax: The 5 Fields

Each scheduled task line has 5 time fields followed by the command. The 5 fields answer, from left to right: at what minute, at what hour, on what day of the month, in what month, and on what day of the week. After them comes the command to run.

THE CRONTAB LINE * * * * * command minute 0-59 time 0-23 day of the month 1-31 month 1-12 day of the week 0-6 (Sun=0) * means "all" — every minute, every hour, every day...

The golden rule

The asterisk * means “any value.” The task only runs when all the fields match the current clock.

# minute hour day month weekday command

* * * * * command

# The line above runs EVERY MINUTE (everything is *)

Examples to read carefully

0 3 * * * # every day at 03h00

30 8 * * 1 # every Monday at 08h30

*/5 * * * * # every 5 minutes

0 */2 * * * # every 2 hours, at minute 0

0 0 1 * * # on the 1st of every month, at midnight

0 9 * * 1-5 # Mon–Fri at 09h00 (business days)

O / means “every N items.” The - and an interval. The comma (1,15) lists specific values.

💡 Tip: use crontab.guru

If you're unsure what a line does, paste it into the site crontab.guru. It translates the expression into plain English ("every 5 minutes", "every Sunday at midnight"). It’s the fastest way to check that you entered the right schedule before saving.

3

crontab -e: Adding Tasks

To view and edit your user's scheduled tasks, use the command crontab. It opens a special file where each line is a scheduled task. You don’t edit this file directly: let the command crontab -e open the editor for you.

1

Open the task editor

$ crontab -e

# The first time, it asks which editor to use.

Select an editor. To change later, run 'select-editor'.

1. /bin/nano <---- easiest

2. /usr/bin/vim.basic

# Choose 1 (nano) by typing 1 and pressing Enter.

2

Add a line at the end of the file

# Runs every day at 03:00

0 3 * * * /home/usuario/backup.sh

Each task is in one line. Use the script's full path to avoid surprises.

3

Save and exit

# In nano: Ctrl+O, Enter (save), then Ctrl+X (exit)

crontab: installing new crontab

The message "installing new crontab" confirms that cron has already registered your scheduled task.

Commands for managing crontab

# Edit the tasks

$ crontab -e

# View (list) the current tasks

$ crontab -l

0 3 * * * /home/usuario/backup.sh

# Delete ALL tasks (be careful)

$ crontab -r

⚠️ Common Error

Problem: "My script runs in the terminal, but cron doesn’t execute anything."
Solution: Almost always, it’s a path issue. Cron runs with an almost empty environment, without your PATH. Always use full paths (e.g.: /usr/bin/python3 /home/usuario/script.py instead of just python3 script.py) and grant execute permission with chmod +x backup.sh.

4

Practical Everyday Examples

Theory only matters when it turns into practice. Here are three tasks that practically every server ends up needing: a daily backup, a log cleanup old ones and one weekly report. Copy it, adapt the paths, and use it.

💾 Daily database backup

Every day at 02h00, compacts the database and saves it with the date in the filename.

# run crontab -e and add:

0 2 * * * pg_dump app | gzip > /backups/app-$(date +\%F).sql.gz

# Result, one file per day:

/backups/app-2026-06-17.sql.gz

/backups/app-2026-06-18.sql.gz

In crontab, the percent sign needs to become \% (with a backslash), or cron will treat it as a line break.

🧹 Cleaning Up Old Logs

Every Sunday at midnight, delete log files older than 30 days.

# Sunday at 04:00 (day of the week = 0)

0 4 * * 0 find /var/log/app -name "*.log" -mtime +30 -delete

-mtime +30 = modified more than 30 days ago. This keeps the logs from filling up the server's disk.

📊 Weekly email report

Every Monday at 08h00, run a script that builds the weekly report and sends it.

# Monday (day of the week = 1) at 08:00

0 8 * * 1 /usr/bin/python3 /home/usuario/relatorio.py

✓ What TO DO

  • ✓Use the full path to scripts and binaries
  • ✓Test the command in the terminal before scheduling it
  • ✓Run heavy tasks overnight

✗ What NOT to do

  • ✗Use relative paths (e.g., ./script.sh)
  • ✗Forget to escape the % with \%
  • ✗Schedule everything for the same minute (overloads the system)
5

Logs: How to Tell Whether Cron Ran

Cron is silent: it runs in the background and doesn’t show anything on your screen. That’s why the most common question is "did it run?". The answer comes from the logs. The system records every time a cron job runs, and you can redirect your command's output to its own file.

👁 Where cron records the run

# Ubuntu/Debian: the log is in syslog

$ grep CRON /var/log/syslog

Jun 17 03:00:01 srv CRON[1234]: (usuario) CMD (/home/usuario/backup.sh)

# On many systems, also:

$ journalctl -u cron --since today

These lines prove that the cron triggered the command. But they don’t show what your command printed or whether it failed. To see that, redirect the output.

Redirect the output to a file

Add >> arquivo.log 2>&1 at the end of the line. That way, both normal output and errors go to the file.

# Save output and errors to backup.log

0 2 * * * /home/usuario/backup.sh >> /home/usuario/backup.log 2>&1

# Then, read the file to check

$ tail -n 20 /home/usuario/backup.log

[2026-06-17 02:00] Backup completed: 1 table, 3.2 MB

What each part means

  • •>> appends to the end of the file (without deleting what was already there).
  • •> (one only) overwrites the file on every run.
  • •2>&1 sends errors to the same place as standard output.

💡 Tip: cron can email you

If a cron job prints something and you no redirects the output; cron tries to email this output to the task owner (variable MAILTO). On servers without email configured, this only creates noise. That's why the usual practice is to always redirect output to a log file and read it from there.

6

Alternative: systemd timers

Cron is great and simple, but there’s a more modern sibling: systemd timers. In module 4.3, you saw systemd managing services. It can also schedule tasks. A timer starts a service at the right time, much like cron, but with more features.

What a timer looks like

There are two files: one .service (what to run) and a .timer (when it runs).

# backup.timer

[Timer]

OnCalendar=*-*-* 03:00:00

Persistent=true

[Install]

WantedBy=timers.target

# Enable and view the active timers

$ systemctl enable --now backup.timer

$ systemctl list-timers

The row Persistent=true runs the task as soon as the machine starts, in case it was turned off at the scheduled time. Simple cron doesn't do this.

⏰ Prefer cron when

  • ✓The task is simple (one command, one schedule)
  • ✓You want to write it and forget about it quickly
  • ✓The server stays on all the time

⚙ Prefer systemd timer when

  • ✓Need to run what you missed while it was off
  • ✓Want logs integrated with journalctl
  • ✓You already manage the rest with systemd

🧠 Analogy: Two Alarm Clocks

Cron is the reliable, straightforward analog bedside alarm clock: you turn the dial, and that’s it. A systemd timer is like a phone alarm app: a smart alarm that catches up on missed runs and keeps a history of when it went off. Both wake you up. Start with cron; when you need the extra features, switch to the timer.

📚 Module Summary

✓
Cron is the server’s alarm clock - runs commands on a set schedule, by itself
✓
5 fields: minute hour day month day-of-week - * = any value
✓
crontab -e, -l, -r - edit, list, and remove tasks
✓
Full path and log - use an absolute path and >> arquivo.log 2>&1
✓
systemd timers - a modern alternative when you need more features

Next Track:

Track 5 - AI Assistants: you already know the terminal, deploys, servers, and automation. Now it’s time to put AI to work with you.