Part of my #DevOpsFromZero series — documenting real KodeCloud tasks with the commands, the reasoning, the mistakes, and the principles behind every decision.
The Task
On all app servers in the Stratos Datacenter, run a cron job that runs the script
/usr/local/bin/users_data.shevery Sunday at 03:30 AM.
Automating maintenance work is one of the most direct quality-of-life improvements in infrastructure. This is cron.
What Is Cron?
Cron is the Linux task scheduler. It runs commands or scripts at specified intervals — hourly, daily, weekly, or at any custom time you define.
Think of cron as a silent operations manager who never forgets. You tell it what to run and when. It runs it. No reminders, no manual triggers, no one needing to be awake at 3:30 AM.
This matters in platform work: database backups, log rotation, health checks, report generation — these all happen on a schedule. If the schedule depends on a person remembering to run a script, the schedule is unreliable.
The Infrastructure
| Server | Hostname | SSH User |
|---|---|---|
| App Server 1 | stapp01 | tony |
| App Server 2 | stapp02 | steve |
| App Server 3 | stapp03 | banner |
Cron Syntax
A crontab entry has five time fields followed by the command:
* * * * * command
│ │ │ │ │
│ │ │ │ └── Day of week (0–7; 0 and 7 are Sunday)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)
For “every Sunday at 03:30 AM”:
- Minute:
30 - Hour:
3 - Day of month:
*(any) - Month:
*(any) - Day of week:
0(Sunday)
The entry:
30 3 * * 0 /usr/local/bin/users_data.sh
Step-by-Step: What I Did
The process is identical on all three servers. Here it is using stapp01 as the example.
1. Connect to the Server
ssh tony@stapp01
2. Open the Crontab Editor
crontab -e
This opens the current user’s crontab file in the default text editor (usually vi or nano depending on the system). Each line is one scheduled job.
3. Add the Cron Entry
Add this line to the crontab:
30 3 * * 0 /usr/local/bin/users_data.sh
Save and exit. Cron automatically detects the change — no service reload needed.
4. Verify the Entry
crontab -l
Output:
30 3 * * 0 /usr/local/bin/users_data.sh
The job is scheduled. ✅
5. Exit and Repeat
exit
Repeat steps 1–4 for stapp02 (as steve) and stapp03 (as banner).
Cron Quick Reference
| Field | Range | Description |
|---|---|---|
| Minute | 0–59 | Minute of the hour |
| Hour | 0–23 | Hour of the day (24-hour) |
| Day of month | 1–31 | Day within the month |
| Month | 1–12 | Month of the year |
| Day of week | 0–7 | 0 and 7 both mean Sunday |
Common patterns:
| Schedule | Cron expression |
|---|---|
| Every minute | * * * * * |
| Every hour | 0 * * * * |
| Every day at midnight | 0 0 * * * |
| Every Sunday at 3:30 AM | 30 3 * * 0 |
| Every first of the month | 0 0 1 * * |
Useful Crontab Commands
crontab -e # Edit your crontab
crontab -l # List current crontab entries
crontab -r # Remove all crontab entries (use carefully)
To view another user’s crontab (as root):
sudo crontab -u username -l
A Note on Script Permissions
Cron will only execute the script if the user running the crontab has permission to execute it. Before scheduling, verify the script is executable:
ls -l /usr/local/bin/users_data.sh
If the execute bit is missing, add it:
sudo chmod +x /usr/local/bin/users_data.sh
This connects directly to Day 4 — execute permission is a prerequisite for cron to run a script, and a missing x bit produces a silent failure.
Key Concepts Recap
| Concept | What It Means |
|---|---|
crontab -e | Opens the current user’s crontab for editing |
crontab -l | Lists all cron entries for the current user |
| Five time fields | Minute, Hour, Day-of-month, Month, Day-of-week |
* wildcard | Means “every” for that field |
Day of week 0 or 7 | Both refer to Sunday |
| Automatic reload | Cron reads the crontab automatically — no service restart needed |
Closing Thought
Day 1: Specify intent explicitly — defaults will betray you. Day 2: No error doesn’t mean correct behaviour — always verify. Day 3: A configuration change is not real until the running service has loaded it. Day 4: Permission problems are layered — test the obvious explanation, then inspect the next layer. Day 5: When a change needs to survive a reboot, only the config file matters. Day 6: If something should happen reliably, don’t rely on remembering it — build a system that remembers for you.
Cron is the simplest form of that principle. Schedule it once. Forget about it.
Part of my #DevOpsFromZero series — documenting real KodeCloud tasks with the commands, the reasoning, the mistakes, and the principles behind every decision.