Cron Jobs & Automation

Learn how Linux automates recurring tasks using cron jobs, systemd timers, and services, and understand how automation powers modern infrastructure.

Difficulty: Beginner
Estimated reading time: 90 min

Introduction

One of the biggest strengths of Linux is automation.

Linux systems are designed to:

• execute recurring tasks
• monitor services
• rotate logs
• create backups
• restart applications
• run maintenance jobs
• schedule scripts automatically

Without automation:

• infrastructure would require constant manual work
• servers would become difficult to manage
• scaling systems would be nearly impossible

This is why automation is deeply connected to:

• DevOps
• cloud infrastructure
• backend engineering
• Linux administration

In Linux, automation traditionally relied on:

cron

But modern Linux systems increasingly use:

systemd timers

Understanding both is extremely important.

Understanding Task Scheduling

What Is Task Scheduling?

Task scheduling means:

Running commands automatically at specific times.

Examples:

Automation allows Linux systems to operate continuously without human interaction.

What Is Cron?

Understanding Cron

Cron is a Linux scheduling system.

The cron daemon continuously runs in the background and checks:

Which jobs should execute now?

Cron has existed for decades and remains heavily used.

The Cron Daemon

The background service is called:

crond

or sometimes:

cron

Check status:

systemctl status cron

or:

systemctl status crond

depending on distribution.

Understanding Crontabs

What Is a Crontab?

A crontab is:

A file containing scheduled jobs.

Each user may have their own crontab.

View current crontab:

crontab -l

Edit crontab:

crontab -e

Choosing an Editor

If Vim is configured:

vim

opens automatically.

Otherwise set editor manually:

export EDITOR=vim

Crontab Syntax

Basic Structure

Example:

* * * * * command

This structure initially looks confusing.

But it becomes logical quickly.

Cron Time Fields

Visual Layout

* * * * * command
│ │ │ │ │
│ │ │ │ └── day of week
│ │ │ └──── month
│ │ └────── day of month
│ └──────── hour
└────────── minute

Common Cron Examples

Run Every Minute

* * * * * echo "hello"

Run Every Day at Midnight

0 0 * * * backup.sh

Run Every Hour

0 * * * * script.sh

Run Every Sunday

0 2 * * 0 cleanup.sh

Run Every 5 Minutes

*/5 * * * * monitor.sh

Very common in monitoring systems.

Real-World Cron Examples

Automated Backup

0 2 * * * /opt/scripts/backup.sh

Runs every day at 2 AM.

Docker Cleanup

0 3 * * 0 docker system prune -f

Weekly cleanup job.

Health Monitoring

*/1 * * * * /opt/scripts/check-api.sh

Runs every minute.

Running Scripts with Cron

Example Script

Create file:

vim backup.sh

Content:

#!/bin/bash

tar -czf /backup/files.tar.gz /home/user/files

Save:

ESC
:wq

Make executable:

chmod +x backup.sh

Add cron job:

0 2 * * * /home/user/backup.sh

Cron Environment Problems

Important Difference

Cron jobs run in a minimal environment.

This often surprises beginners.

Example:

PATH may be different

Commands working manually may fail inside cron.

Safer Cron Commands

Bad:

docker ps

Better:

/usr/bin/docker ps

Use full paths whenever possible.

View Current PATH

echo $PATH

Find executable location:

which docker

Redirecting Cron Output

Why Output Matters

Cron automatically emails output on some systems.

More commonly:

• output disappears
• errors become invisible

Always redirect logs properly.

Save Output to File

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

Breakdown:

Very important in production systems.

Cron Logging

View Cron Logs

Ubuntu / Debian:

grep CRON /var/log/syslog

RHEL / Fedora:

grep CRON /var/log/cron

Useful for debugging scheduled jobs.

System-Wide Cron Jobs

Cron Directories

Linux supports scheduled jobs through directories:

Scripts placed there execute automatically.

Example

Create script:

sudo vim /etc/cron.daily/cleanup

Make executable:

sudo chmod +x /etc/cron.daily/cleanup

Now Linux executes it daily.

Common Cron Problems

Script Works Manually but Not in Cron

Usually caused by:

• missing PATH
• permissions
• wrong working directory
• missing environment variables

Relative Paths

Bad:

./backup.sh

Better:

/home/user/backup.sh

Cron jobs should use absolute paths.

Missing Execute Permissions

Fix:

chmod +x script.sh

Introduction to systemd Timers

Why systemd Timers Exist

Modern Linux systems increasingly use:

systemd timers

instead of cron.

Advantages:

• better logging
• dependency management
• easier monitoring
• integrated service control
• more flexible scheduling

Many modern distributions prefer systemd timers for infrastructure automation.

Understanding systemd Units

systemd Uses Unit Files

systemd manages resources through unit files.

Examples:

Timers usually trigger services.

Creating Your Own Service

Why Custom Services Matter

Many applications need to run continuously.

Examples:

• Node.js apps
• Python APIs
• monitoring scripts
• background workers

Instead of manually running commands:

node app.js

Linux can manage them automatically using systemd services.

Example Custom Service

Step 1 — Create Script

Create file:

vim /opt/hello.sh

Content:

#!/bin/bash

while true
do
    echo "Service is running"
    sleep 10
done

Save and quit:

ESC
:wq

Make executable:

chmod +x /opt/hello.sh

Step 2 — Create Service File

Create:

sudo vim /etc/systemd/system/hello.service

Content:

[Unit]
Description=My Hello Service
After=network.target

[Service]
ExecStart=/opt/hello.sh
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Understanding Service File Sections

[Unit]

General metadata and dependencies.

Example:

After=network.target

Meaning:

Start after networking is ready

[Service]

Defines actual process behavior.

Important options:

[Install]

Defines startup behavior.

Example:

WantedBy=multi-user.target

Means:

Start during normal system boot

Managing Custom Services

Reload systemd

After creating service files:

sudo systemctl daemon-reload

Very important.

systemd must reload configurations.

Start Service

sudo systemctl start hello

Enable Service on Boot

sudo systemctl enable hello

Check Status

systemctl status hello

View Logs

journalctl -u hello -f

This is real-world Linux service management.

Creating a systemd Timer

Step 1 — Create Service

Example:

sudo vim /etc/systemd/system/backup.service

Content:

[Unit]
Description=Backup Service

[Service]
Type=oneshot
ExecStart=/opt/backup.sh

Understanding Type=oneshot

This tells systemd:

Run command once and exit

Perfect for scheduled jobs.

Step 2 — Create Timer

Create:

sudo vim /etc/systemd/system/backup.timer

Content:

[Unit]
Description=Run Backup Every Day

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Understanding Timer Options

OnCalendar

Defines schedule.

Examples:

Persistent=true

If system was offline:

Missed jobs execute after boot

Very useful.

Cron traditionally handles this less elegantly.

Starting Timers

Reload systemd

sudo systemctl daemon-reload

Enable Timer

sudo systemctl enable --now backup.timer

View Timers

systemctl list-timers

Very useful command.

Cron vs systemd Timers

Cron Advantages

• simple
• old and stable
• widely known

systemd Timer Advantages

• better logging
• dependency management
• integrated services
• easier monitoring
• persistent scheduling
• cleaner infrastructure integration

Modern Linux increasingly favors systemd timers.

Real-World Automation Examples

Automatic Backups

• cron jobs
• systemd timers
• cloud snapshots

Container Cleanup

docker system prune

scheduled automatically.

Health Monitoring

Check APIs every minute.

Log Rotation

Automatically remove old logs.

Security Scanning

Scheduled vulnerability checks.

Debugging Scheduled Jobs

Cron Debugging

Check logs:

grep CRON /var/log/syslog

systemd Timer Debugging

Check timer status:

systemctl status backup.timer

View logs:

journalctl -u backup.service

Linux Philosophy and Automation

Linux systems are designed to:

• automate repetitive tasks
• run unattended
• expose everything through scripts
• integrate small reusable tools

Automation is deeply connected to Unix philosophy.

Why Automation Matters for DevOps

Modern infrastructure depends heavily on automation.

Examples:

Infrastructure at scale would be impossible without automation.

The Bigger Picture

Once you understand cron jobs and systemd automation, Linux starts feeling much more powerful.

You begin understanding:

• how servers operate autonomously
• how recurring infrastructure tasks work
• how services stay alive automatically
• how production systems self-manage

Automation is one of the core reasons Linux became dominant in modern infrastructure.

What Comes Next

In the next chapter, we will explore:

• Linux permissions
• sudo and privilege escalation
• firewall basics
• SSH hardening
• fail2ban
• updates and patching
• security best practices

This is where Linux administration starts becoming security-focused.