Day 18 - Scheduling with Cron (Real-World Use Cases)

One of the biggest powers of Linux (and DevOps in general) is automation without human intervention. Today I studied scheduling in Linux — a core concept every DevOps Engineer must master.

In real production systems, you cannot sit and run commands manually. You need tasks like backups, monitoring, log cleanup, service restarts, and reporting to run automatically. That is where cron comes in.

---

What is Scheduling in Linux?

Linux offers two ways of scheduling tasks:

1. One-time scheduling → using the at command

2. Recurring scheduling → using cron jobs

For DevOps, cron jobs are the real workhorse. They allow scripts or commands to run repeatedly at defined intervals.

Common use cases:

• Rotating logs so servers do not crash due to full disk

• Taking daily database backups

• Syncing data with cloud storage

• Monitoring services and restarting them if needed

• Sending system health reports to administrators

---

Cron Basics

A cron job has 5 fields followed by the command:

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

Example:

0 2 * * * command

Runs at 2:00 AM every day.

I used crontab.guru to quickly check and validate cron expressions.

---

Real DevOps Cron Examples

Instead of just theory, I practiced production-like cron jobs. Here are the examples with explanations.

1. Log Rotation – Clean Old Logs

0 2 * * * find /var/log/myapp/ -type f -name "*.log" -mtime +7 -exec rm -f {} \;

• Runs daily at 2 AM

• Deletes .log files older than 7 days

• Prevents servers from crashing due to disk full issues

Learning: This is one of the simplest yet most important jobs in production.

---

2. Database Backup

0 1 * * * mysqldump -u root -pYourPassword mydatabase > /backups/mydb_$(date +\%F).sql

• Runs daily at 1 AM

• Takes a MySQL dump and saves with current date

• Protects against data loss

Learning: A must-have for every application. In production, this usually integrates with cloud storage like S3.

---

3. Sync Files to AWS S3

0 0 * * * aws s3 sync /var/data/ s3://mycompany-backups/data/

• Runs every midnight

• Syncs local /var/data/ with S3 bucket

• Ensures offsite/cloud backup

Learning: Shows how cron and cloud CLI tools combine for reliability.

---

4. Restart a Service if It Is Down

*/5 * * * * systemctl is-active --quiet nginx || systemctl restart nginx

• Runs every 5 minutes

• Checks if Nginx is active, restarts if not

• Keeps services available without manual effort

Learning: This is a mini self-healing mechanism for critical services.

---

5. Daily System Resource Report (Email)

Script /home/ubuntu/resource_alert.sh:

#!/bin/bash
echo "System Report - $(date)"
echo "-----------------------"
echo "CPU Load:"
uptime
echo ""
echo "Memory Usage:"
free -m
echo ""
echo "Disk Usage:"
df -h

Make executable:

chmod +x /home/ubuntu/resource_alert.sh

Schedule in cron:

MAILTO=admin@example.com
0 8 * * * /home/ubuntu/resource_alert.sh

• Runs daily at 8 AM

• Sends CPU, memory, and disk usage report to email

Learning: This is proactive monitoring before issues occur.

---

Practice Task: Health Check Every 30 Minutes

I also wrote a simple script to log system health:

#!/bin/bash
echo "Health Check at $(date)"
uptime
df -h
free -m

Cron entry:

*/30 * * * * /home/ubuntu/healthcheck.sh >> /var/log/healthcheck.log

Now I have a file that automatically tracks health checks every 30 minutes. This is how observability starts small before advanced tools like Prometheus or Grafana are introduced.

---

Key Takeaways

• Automation mindset is essential in DevOps. Cron is often the first step.

• Every job must be thought of in terms of: what happens if this is not done?

  • No log cleanup → Disk full → System crash

  • No database backup → Data loss → Business loss

  • No service check → Downtime → Users unhappy

• Even simple cron jobs add significant reliability value.

---

Final Reflection

Today’s lesson was not just about cron syntax. It was about thinking like a DevOps Engineer — asking:

• What must run on schedule?

• What happens if this fails?

• How can I automate without manual intervention?

Cron is the quiet hero of Linux — simple, invisible, but keeping entire systems running smoothly.